pr0gg3r

Was ist daran falsch? Kann ja jeder so machen, wie er es für richtig hält. Die Altersarmut in Deutschland nimmt definitiv nicht aus diesem Grund zu, sondern weil die Renten immer weniger werden bzw. nach hinten geschoben werden, es auch Verlierer bei der Globalisierung gibt, wirtschaftliche Krisen, politische Entscheidungen usw. Die goldenen Zeiten sind vorbei, bei denen sich selbst ein Metzger oder Flaschner ein Haus bauen konnten. Und wem ist das verschuldet? Diesen, die genau so über die "junge Generation" reden, die ihr Haus, ihr dickes Auto, ihre Renten usw. haben. Die für unsere Generation entschieden haben, aber nicht im Sinne der Nachhaltigkeit, sondern dass ihre Bäuche fett bleiben, drauf gesch*** was nach ihnen kommt. Wir können nicht mehr sagen: "wir bilden uns, haben einen guten und sicheren Job in einer Firma bis zu Rente und haben dann noch ein schönes hohes Alter". Wir sind geplagt von Unsicherheiten, von falschen Versprechen. Wir sehen es jeden Tag. Aber nein, all das, was wir nicht mehr erreichen können liegt ja nur an unserer Faulheit. Daran, dass niemand mehr arbeiten möchte. Dass wir zu einer Spaßgesellschaft mutiert sind und von Arbeit ja nichts hören möchten. Sorry, aber da macht "ihr" es euch zu einfach. In vielen Punkten habt "ihr" versagt, ohne es wahrhaben zu wollen, ihr zeigt mir dem Finger auf uns als wären wir der Abschaum der Gesellschaft, weil wir es nicht so machen, wie ihr es gemacht habt. Aber euch kommt nicht in den Sinn, dass wir es gar nicht so machen können, dass wir gar nicht mehr das erreichen können, was ihr geschaffen habt. Genau deshalb suchen wir uns andere Werte, andere Träume und andere Ziele, als "eure Generation" es für richtig hielt. Ja, der Generationenkonflikt existiert Und früher war alles besser. Aber wer hat es vermasselt? Ja ja ja - die junge Generation von heute. 

Was ist daran falsch? Kann ja jeder so machen, wie er es für richtig hält. Die Altersarmut in Deutschland nimmt definitiv nicht aus diesem Grund zu, sondern weil die Renten immer weniger werden bzw. nach hinten geschoben werden, es auch Verlierer bei der Globalisierung gibt, wirtschaftliche Krisen, politische Entscheidungen usw. Die goldenen Zeiten sind vorbei, bei denen sich selbst ein Metzger oder Flaschner ein Haus bauen konnten. Und wem ist das verschuldet? Diesen, die genau so über die "junge Generation" reden, die ihr Haus, ihr dickes Auto, ihre Renten usw. haben. Die für unsere Generation entschieden haben, aber nicht im Sinne der Nachhaltigkeit, sondern dass ihre Bäuche fett bleiben, drauf gesch*** was nach ihnen kommt. Wir können nicht mehr sagen: "wir bilden uns, haben einen guten und sicheren Job in einer Firma bis zu Rente und haben dann noch ein schönes hohes Alter". Wir sind geplagt von Unsicherheiten, von falschen Versprechen. Wir sehen es jeden Tag. Aber nein, all das, was wir nicht mehr erreichen können liegt ja nur an unserer Faulheit. Daran, dass niemand mehr arbeiten möchte. Dass wir zu einer Spaßgesellschaft mutiert sind und von Arbeit ja nichts hören möchten. Sorry, aber da macht "ihr" es euch zu einfach. In vielen Punkten habt "ihr" versagt, ohne es wahrhaben zu wollen, ihr zeigt mir dem Finger auf uns als wären wir der Abschaum der Gesellschaft, weil wir es nicht so machen, wie ihr es gemacht habt. Aber euch kommt nicht in den Sinn, dass wir es gar nicht so machen können, dass wir gar nicht mehr das erreichen können, was ihr geschaffen habt. Genau deshalb suchen wir uns andere Werte, andere Träume und andere Ziele, als "eure Generation" es für richtig hielt. Ja, der Generationenkonflikt existiert Und früher war alles besser. Aber wer hat es vermasselt? Ja ja ja - die junge Generation von heute. 

Was ist daran falsch? Kann ja jeder so machen, wie er es für richtig hält. Die Altersarmut in Deutschland nimmt definitiv nicht aus diesem Grund zu, sondern weil die Renten immer weniger werden bzw. nach hinten geschoben werden, es auch Verlierer bei der Globalisierung gibt, wirtschaftliche Krisen, politische Entscheidungen usw. Die goldenen Zeiten sind vorbei, bei denen sich selbst ein Metzger oder Flaschner ein Haus bauen konnten. Und wem ist das verschuldet? Diesen, die genau so über die "junge Generation" reden, die ihr Haus, ihr dickes Auto, ihre Renten usw. haben. Die für unsere Generation entschieden haben, aber nicht im Sinne der Nachhaltigkeit, sondern dass ihre Bäuche fett bleiben, drauf gesch*** was nach ihnen kommt. Wir können nicht mehr sagen: "wir bilden uns, haben einen guten und sicheren Job in einer Firma bis zu Rente und haben dann noch ein schönes hohes Alter". Wir sind geplagt von Unsicherheiten, von falschen Versprechen. Wir sehen es jeden Tag. Aber nein, all das, was wir nicht mehr erreichen können liegt ja nur an unserer Faulheit. Daran, dass niemand mehr arbeiten möchte. Dass wir zu einer Spaßgesellschaft mutiert sind und von Arbeit ja nichts hören möchten. Sorry, aber da macht "ihr" es euch zu einfach. In vielen Punkten habt "ihr" versagt, ohne es wahrhaben zu wollen, ihr zeigt mir dem Finger auf uns als wären wir der Abschaum der Gesellschaft, weil wir es nicht so machen, wie ihr es gemacht habt. Aber euch kommt nicht in den Sinn, dass wir es gar nicht so machen können, dass wir gar nicht mehr das erreichen können, was ihr geschaffen habt. Genau deshalb suchen wir uns andere Werte, andere Träume und andere Ziele, als "eure Generation" es für richtig hielt. Ja, der Generationenkonflikt existiert Und früher war alles besser. Aber wer hat es vermasselt? Ja ja ja - die junge Generation von heute. 

Was ist daran falsch? Kann ja jeder so machen, wie er es für richtig hält. Die Altersarmut in Deutschland nimmt definitiv nicht aus diesem Grund zu, sondern weil die Renten immer weniger werden bzw. nach hinten geschoben werden, es auch Verlierer bei der Globalisierung gibt, wirtschaftliche Krisen, politische Entscheidungen usw. Die goldenen Zeiten sind vorbei, bei denen sich selbst ein Metzger oder Flaschner ein Haus bauen konnten. Und wem ist das verschuldet? Diesen, die genau so über die "junge Generation" reden, die ihr Haus, ihr dickes Auto, ihre Renten usw. haben. Die für unsere Generation entschieden haben, aber nicht im Sinne der Nachhaltigkeit, sondern dass ihre Bäuche fett bleiben, drauf gesch*** was nach ihnen kommt. Wir können nicht mehr sagen: "wir bilden uns, haben einen guten und sicheren Job in einer Firma bis zu Rente und haben dann noch ein schönes hohes Alter". Wir sind geplagt von Unsicherheiten, von falschen Versprechen. Wir sehen es jeden Tag. Aber nein, all das, was wir nicht mehr erreichen können liegt ja nur an unserer Faulheit. Daran, dass niemand mehr arbeiten möchte. Dass wir zu einer Spaßgesellschaft mutiert sind und von Arbeit ja nichts hören möchten. Sorry, aber da macht "ihr" es euch zu einfach. In vielen Punkten habt "ihr" versagt, ohne es wahrhaben zu wollen, ihr zeigt mir dem Finger auf uns als wären wir der Abschaum der Gesellschaft, weil wir es nicht so machen, wie ihr es gemacht habt. Aber euch kommt nicht in den Sinn, dass wir es gar nicht so machen können, dass wir gar nicht mehr das erreichen können, was ihr geschaffen habt. Genau deshalb suchen wir uns andere Werte, andere Träume und andere Ziele, als "eure Generation" es für richtig hielt. Ja, der Generationenkonflikt existiert Und früher war alles besser. Aber wer hat es vermasselt? Ja ja ja - die junge Generation von heute. 

Was ist daran falsch? Kann ja jeder so machen, wie er es für richtig hält. Die Altersarmut in Deutschland nimmt definitiv nicht aus diesem Grund zu, sondern weil die Renten immer weniger werden bzw. nach hinten geschoben werden, es auch Verlierer bei der Globalisierung gibt, wirtschaftliche Krisen, politische Entscheidungen usw. Die goldenen Zeiten sind vorbei, bei denen sich selbst ein Metzger oder Flaschner ein Haus bauen konnten. Und wem ist das verschuldet? Diesen, die genau so über die "junge Generation" reden, die ihr Haus, ihr dickes Auto, ihre Renten usw. haben. Die für unsere Generation entschieden haben, aber nicht im Sinne der Nachhaltigkeit, sondern dass ihre Bäuche fett bleiben, drauf gesch*** was nach ihnen kommt. Wir können nicht mehr sagen: "wir bilden uns, haben einen guten und sicheren Job in einer Firma bis zu Rente und haben dann noch ein schönes hohes Alter". Wir sind geplagt von Unsicherheiten, von falschen Versprechen. Wir sehen es jeden Tag. Aber nein, all das, was wir nicht mehr erreichen können liegt ja nur an unserer Faulheit. Daran, dass niemand mehr arbeiten möchte. Dass wir zu einer Spaßgesellschaft mutiert sind und von Arbeit ja nichts hören möchten. Sorry, aber da macht "ihr" es euch zu einfach. In vielen Punkten habt "ihr" versagt, ohne es wahrhaben zu wollen, ihr zeigt mir dem Finger auf uns als wären wir der Abschaum der Gesellschaft, weil wir es nicht so machen, wie ihr es gemacht habt. Aber euch kommt nicht in den Sinn, dass wir es gar nicht so machen können, dass wir gar nicht mehr das erreichen können, was ihr geschaffen habt. Genau deshalb suchen wir uns andere Werte, andere Träume und andere Ziele, als "eure Generation" es für richtig hielt. Ja, der Generationenkonflikt existiert Und früher war alles besser. Aber wer hat es vermasselt? Ja ja ja - die junge Generation von heute. 

Ich sehe das wie Goulasz und beurteile nicht nur das Gehalt als den "Lohn". Es geht immer um das Gesamtpaket. Dass immer jemand mehr verdient als ich, ist klar. Wenn ich mir deswegen schlaflose Nächte machen würde, dann könnte ich nie ruhig schlafen. Jeder Mensch hat seine Stationen im Leben und steht immer woanders als die Person mit der er sich darüber austauscht. Selbst bei gleichem Alter können die Wege, Branchen und allgemeinen Umstände dafür sorgen, dass es zu Unterschieden kommt.
Ich bin neidisch, wenn Leute davon sprechen, dass in ihrem Job die Unternehmenssprache Englisch ist. Wenn die Struktur eine andere ist und damit flexibler ist. Wenn bestimmte Abläufe strukturierter beschrieben sind. Wenn dort mehr für die Fort- und Weiterbildung getan wird. Solche Sachen.
Aber das beschränkt sich auf meine Branche. Wenn ich mich aber in eine Pflegekraft versetze und sehe, was man in der IT verdienen kann, dann würde ich auch neidisch werden. Da mein Verdienst als Pflegekraft dann im Vergleich zur IT nach meinem Dafürhalten nicht der erbrachten Leistung entspräche.
Aber auch hier: Wenn man darum weiß, aber in dem Job aufgeht, das Klima toll ist und man für sich das richtige gefunden hat - dann kann einem das allemal wichtiger sein als "....aber die kriegen so und so viel".
Zumal ein Vergleich mit "der IT" sowieso schwierig ist. Ein Supportler kriegt ein weitaus anderes Gehalt, als ein Projektleiter.
Ich überlege zur Zeit, mich umzuorientieren. Mir ist bewusst, dass das mit Geldeinbußen einher kommen wird. Aber wenn mich die Arbeit dann anders oder sogar mehr erfüllt, ist das auch eine ganze Menge wert.

Täglich grüßt das Murmeltier äh... der Fachkräftemangel:
http://www.heise.de/newsticker/meldung/Bayerische-Unternehmen-suchen-IT-Fachkraefte-3290336.html

Wenn ich zwei Tage lang (und erst recht fünf Wochen lang) "Klicktests" machen würde, würde ich mich fragen, wie sich diese automatisieren lassen  

Na ja, ich arbeite inzwischen seit einigen Jahren als Softwareentwickler und das, was ich schon in einigen Firmen an Code gesehen habe, geht echt unter keine Kuhhaut. Da schreiben selbst Entwickler, die 20+ Jahre Berufserfahrung haben, den allergrößten Mist an Code, den man sich nur vorstellen kann. Da werden Design Patterns auf abstruse Art- und Weisen oder sogar komplett falsch implementiert oder viele haben selbst nach 20 Jahren die Objektorientierung nicht verstanden und schreiben weiterhin spaghetticode wie in alten C-Zeiten.
An der Software, wo ich jetzt arbeite, hat man statische Klassen aus Faulheit verwendet. Damit man die Klassen nicht instanziieren braucht, hat man sie statisch gemacht (yeeaah! Man spart sich eine Zeile Code...). Hier wurde Mikro-Optimierung auf die Spitze getrieben und von solchen Klassen gibt es hunderte und diese Klassen sorgen in Unittests immer wieder für Probleme, weil z.B. die Methoden Queries an die Datenbank schicken. Der Unittest ist dann von der Datenbank abhängig. Also testet man im Unittest nicht mehr die Methoden an sich, sondern schon komplexe Programm-Strukturen auf einen Schlag. Das Problem ist nun, dass man von statischen Klassen nicht erben und somit nicht mocken kann. Martin Fowler hatte diesbezüglich mal ein Blog-Eintrag geschrieben. Sein Beispiel ist aber relativ trivial. Stell dir mal vor, du hast im Code hunderte solcher Klassen, die hunderte von Abhängigkeiten besitzen, weil man laufe der Jahren die Klassen immer um weitere Methoden ergänzt hat und die Klassen nun mehrere Tausend Zeilen beinhalten. Ist ja auch so schön einfach, einfach statische Klassen zu erweitern ...
Mir persönlich geht es auch eher darum, dass du ein gespürt dafür bekommst, wo die Probleme bei statischen Methoden/Klassen liegen und dass man schon wissen sollte, wann dieses Schlüsselwort angebracht ist und wann nicht. Nur weil man die Syntax versteht, heißt es noch lange nicht, dass man auch sauberen Code schreiben kann und das finde ich viel wichtiger als so manches andere aber das bekommt man von Firmen nicht so richtig beigebracht, weil man lieber aufgrund des Zeitdrucks lieber schmutzigen Code schreibt, der zwar jetzt schnell geschrieben werden kann und somit kostengünstig ist aber spätestens in einem halben Jahr hohe Kosten verursacht, weil der Code unwartbar ist. 

Mit Kunden kann ich in solchen Situationen ganz gut umgehen. Das lasse ich auch nicht zu nah an mich ran. Sind ja 'nur' Kunden.
Viel schlimmer finde ich, wenn man solche Kollegen hat. Ich arbeite in der Beratung. Und musste mir schon mehrmals von Kollegen anhören "Ihr Entwickler macht ja eh nix." "Das ist doch schnell programmiert" "das kann doch gar nicht so viel Zeit in anspruch nehmen." "Du hast doch eh nix zu tun"...
 
Wenn man sowas ständig von Kollegen hört, ist das echt ätzend. Habe da leider die Erfahrung gemacht dass einige Kollegen einfach nicht abschätzen können, was ich den ganzen Tag zu tun habe. Und nur, weil ich nicht den ganzen Tag in Meetings verbringe, heißt es ja nicht, dass ich an meinem Schreibtisch sitze und aus dem Fenster schaue.....

Der Arbeitgeber braucht aber Möglichkeiten, dich zu bewerten und da können deine Antworten alleine nicht die Lösung sein, da man sich selbst nie objektiv einschätzt. Natürlich bist zu zuverlässig, natürlich arbeitest du ordentlich und bist pünktlich. Aber das sagt jeder von sich. Die Unterschiede zwischen den Bewerbern werden genau durch "Quatschfragen" und den Reaktionen aus diesen herausgefiltert.
Und sorry, aber da verlierst du, wenn du nicht bereit bist, dich darauf einzulassen. Denn Offenheit gegenüber etwas Neuem und Unbekannten ist durchaus eine Stärke - gerade wenn es um Führungsqualitäten geht.
 

Hallo,
altes Thema aber ich mag es kurz aufgreifen. Zu meiner Person: FIAE 2000 ; im Jahr 2001 nach einem missglückten Berufsstart (kleine Hardware Bude) über ein Düsseldorfer Consulting Unternehmen in den Bereich Softwaretest gerutscht. Ich mache den Job also jetzt bereits einige Jahre und ich hasse es mittlerweile!
 
Die erste Zeit (2001 - 2003) als  Consultant für ein neu gegründetes Unternehmen tätig gewesen. Vorrangiger Einsatz als Tester in Telekommunikationsunternehmen. Teilweise etwas zu testen, oft aber nichts. Fast immer 90 km Anfahrt am Tag (Firmenwagen aber Reisezeit = keine Arbeitszeit) um dann festzustellen, das aufgrund eines "Wartungsfensters" die Systeme wieder nicht zur Verfügung stehen. Also chatten im Internet und warten das irgendwas geht. Meist ging nix. Hat auch keinen interessiert. Oder aber es gab bei anderen Kunden erst gar kein Internetzugang (nur Intranet) und die Tätigkeit bestand in der Anfertigung eines täglichen Reports für die Projektleiter (Aufwand < 30 Minuten). Über das Softwaretesten hab ich wenig gelernt in der Zeit. Hat auch keinen interessiert. Fortbildungen gab es samstags. Hab alles mitgenommen was ging.
 
2003 dann glücklicherweise die Welt des Consultants verlassen und als Softwaretester bei einem Telekommunikationsunternehmen angefangen. Ich darf schon behaupten, dass die "angebotene" vertragliche Situation als recht positiv zu sehen war. Tarifvertraglich geregelt, stundentechnisch mit 38.5 ok, Gehalt war eher gering (~1700€ netto) aber ich war ja noch "Junior Tester". Die "reale Welt" sah dann schon anders aus: 16 - 17 Releases im Jahr, am Tag des Release "open End" (14 - 18 Stunden keine Seltenheit), kein Überstundenausgleich, keine Sonderzahlungen, keine Gehaltserhöhung. Das Testmanagement war extern besetzt und ließ das gesamte Testteam (5 - 7 Mitarbeiter) für den Projekterfolg gnadenlos "über die Klinge" springen. Es war immer genau der eine Fehler, den man übersehen hatte, der zu abmahnungsähnlichen Gesprächen geführt hat. Die 400 Abweichungen die man gefunden hatte spielten da keine Rolle.
Auch nicht uninteressant zu wissen, das in den ~5 Jahren 4 Entwicklungsleiter das Unternehmen verlassen haben und ein Austausch von rund 70 Entwicklern stattgefunden hat. Fortbildungen gab es 2-3 im Jahr. Hab auch hier alles mitgenommen was ging.
Über das Softwaretesten hab ich sehr viel gelernt in der Zeit und auch die ersten ISTQB Zertifizierungen mitgenommen. Das war auch die einzige Firma, bei der das Softwaretesten einen Wert (in Form von Wertschätzung) hatte und wir Tester wirklich gebraucht und gefragt wurden.
 
Ende 2008 (fast völlig) ausgebrannt mit einer der vielen Kündigungswellen die Firma von selber verlassen und bei einer mittelständischen Firma der Kreditwirtschaft angeheuert. 40 Stundenwoche, kein Tarifvertrag, kein Überstundenausgleich. Hörte sich trotzdem erstmal alles gut an. Die "reale Welt" sah dann schon anders aus:
Softwaretesten in Form von Excel Tabellen mit imaginären Testfällen. Ausschließlich Bugzilla und sonstige Open-Source-Software im Einsatz. Für eine 60€ (sechzig) - Lizenz monatelang gekämpft. Als dann der Teilprojektleiter (menschlich und fachlich sehr guter Kollege) das Unternehmen verließ wurde das Testteam (4 gesamt) in eines der hintersten Büros umgezogen. Die Aufgaben nahmen ab, die Mittagspausen mit Spaziergängen wurden länger, nach 1 Jahr gab es fast nichts mehr zu tun. Nachfragen beim Vorgesetzten erbrachten nichts.  Also fuhr man morgens hin (68 km), setzte sich auf den Hintern, spielte den Tag eine Wirtschaftssimulation und durchforstete die Stellenbörsen. Oder hörte sich die Klagen vom Azubi an, das er bald ganz Wikipedia gelesen habe.
Es kam wie es kommen muss: Ein neuer Investor kam, räumte auf und entließ uns Tester erstmal alle. Wir hatte 10 Minuten Zeit unsere Sachen zu packen und wurden dann wie Verbrecher vor die Türe gesetzt. War zwar rechtlich unwirksam aber da standen wir erstmal.
Über das Softwaretesten hab ich sehr viel vergessen in der Zeit aber zumindest eine weitere ISTQB Zertifizierungen mitgenommen. Schulungen? Nur gegen 4-jahres Rückzahlungsverpflichtungen!
 
Ende 2011 dann nach 3-monatiger Freistellung in eine kleine Firma für Energiewirtschaft gewechselt. Bester Chef, den ich jemals hatte! Das erste Jahr dort war bislang das einzige Jahr, in dem ich mich in der IT wohlgefühlt habe. Strukturierte Prozesse, Umgang miteinander fair und auch mit guter Streitkultur. Fokus auf Projekterfolg. Hab mich in alle Richtungen angestrengt; wollte dort endlich heimisch sein. War das erste mal Testmanager mit einem eigenen Team (studentische Hilfskräfte). Habe die (Entwickler) Kollegen im Testen geschult und zur ISTQB Prüfung geschickt. Haben alle bestanden.
Und dann wandelte sich das Blatt wieder. Die Gewinne brachen ein und es gab die ersten Entlassungen, die aber nicht offen kommuniziert wurden. Die Verträge meiner studentischen Hilfskräfte wurden nicht verlängert; geredet hat mit mir vorher keiner. Mir wurde kommuniziert, dass ich nicht entlassen werde hab es  aber irgendwie nicht geglaubt da sich auch die zukünftige Projektsituation als sehr unklar herausstellte und innerhalb von 2 Monaten völliges Chaos herrschte. Zudem war ich auf einmal quasi alleine auf weiter Flur. Hab die Reißleine gezogen und bin gegangen
Habe dort das Softwaretesten eingeführt, war gefordert und wurde gefördert. Schulungen überhaupt kein Problem.
 
Anfang 2014 ergab sich die Möglichkeit in ein großes, kommunales IT Unternehmen zu wechseln welches in Gänze Anteilseigener der öffentlichen Hand (Städte und Gemeinden) besaß. In der gesamten Firmengeschichte niemals Entlassungen. Tarifvertrag, Altersvorsorge und Arbeitszeitkonto. Jetzt hatte ich es geschafft oder aber eben wieder nicht.
Es gab kein Softwaretesten im Unternehmen. Dies galt es zu etablieren. Also Toolauswahl, Schulungen organisiert, Prozesse definiert und sich abnehmen lassen. Ich zitiere den Vorstand der Geschäftsführung "Sie sind genau der Mann den wir brauchen. Wir müssen unbedingt testen". Der Entwicklungs-Bereich indes war unorganisiert, viele individuelle Softwareprodukte, nicht definierte Prozesse, gefühlt hunderte von Technologien im Einsatz die man nicht im Griff hatte. Das erste Projekt lief gut, der Entwickler war wenig genervt durch die ständig neu gemeldeten Abweichungen. Und am Ende stand ein Softwareprodukt welches (zumindest in meiner Zeit) zu keiner einzigen Supportanfrage geführt hat. Bingo!
Das 2. Projekt war größer und ging voll in die Hose. Weit über 400 Fehler ließen sowohl den Projektleiter als auch mich verzweifeln. Aber: Nun war testen auf einmal zu teuer! Es ging nicht mehr darum, dass die Entwickler das Pflichtenheft nicht lesen und ein Fehler nach dem anderen produzieren. Das stand in den ganzen Jahren übrigens niemals im Focus. Das Projekt lief nach kurzer Zeit völlig aus dem Ruder, der Projektleiter steuerte wie wild dagegen aber die Entscheider entschieden nicht.
Auch in anderen Bereichen brachen die Gewinne leicht (!) ein und die ersten Leute in der Probezeit wurden frei gestellt. Es kam wie es kommen musste: Termin bei der Geschäftsführung folgte. "Testen ist uns zu teuer. Es liegt nicht an Ihnen. Sie sind ein sehr guter Mann. Aber was können wir den tun um das Arbeitsverhältnis aufzulösen?". Den Projektleiter traf es im Übrigen genauso wie mich.
Flugs was neues gefunden und mich auf einen Aufhebungsvertrag eingelassen.
Habe dort das Softwaretesten eingeführt, wurde nicht sonderlich gefördert und habe mich zeitweise sogar als Fremdkörper gefühlt. Wäre von selber aber trotzdem nicht gegangen. Schulungen wurde für mich nicht genehmigt, Entwickler bekamen alles was sie wollten (auch wenn es unnütz war).
 
Aktuell (seit Ende 2015) 38 Stundenwoche, Altersvorsorge und Arbeitszeitkonto. Sehr gute vertragliche Konditionen aber völlig unstrukturiert und ohne klare Zielsetzung. Es gab kein Softwaretesten im Unternehmen. Also wieder von vorne: Toolauswahl, Schulungen organisiert, Prozesse definiert und sich abnehmen lassen. Zwischenzeitlich habe ich die ersten Kollegen im Testen geschult und zur ISTQB Zertifizierungen geschickt. Haben fast alle bestanden.
Mal sehen was nun noch so kommt.
 
Fazit:
Es scheint grundsätzlich ein sehr beliebtes Mittel der Firmen zu sein, die Mitarbeiter die man los werden möchte in die hintersten Ecken zu verfrachten, die Aufgaben zu reduzieren und abzuwarten wie lange sie das durchhalten. Gerade im Bereich des Softwaretest sind mir viele Fälle bekannt. Bei Einbruch der Gewinne wird das Testen zu teuer  und die Testabteilung ist das erste was zur Disposition steht.
 
Ich gehe mittlerweile auf die 50 zu, sehe meinen Einstieg in die IT als eher "ungeschickt gewählt" an und würde lieber was anderes machen. Ich würde auch niemandem raten, Softwaretester oder Testmanager zu werden.  Der Job ist hart ("Entwickeln ist konstruktiv, Testen ist destruktiv) auch wenn man volle Rückendeckung der Vorgesetzten hat, die Stellen sind rar (im Vergleich zu Entwicklern) und man ist der erste der draußen ist, wenn die Gewinne einbrechen.
Gruß
Holger

Ein Adler, mit dem Blick auf Allem und jeder Kleinigkeit

@gokyil1234
Man merkt einfach, dass du noch sehr viele Defizite hast. Das betrifft vor allem Grundlagen wie das Rechnen mit Bits und Bytes, Datentypen, ADSL/VDSL, NAS, Raid, AIDA, BAB, verschiedene Kostenarten, VPN, uvm. Die müssen einfach sitzen. Zwar auch nicht hundert prozentig, aber bei dir was (leider) fast in allen Grundlagen Fehler drin.
So schade es ist, damit hast du die Prüfung in meinen Augen vollkommen gerechtfertigt nicht bestanden, denn eine Ausbildung bereitet für den Beruf vor, du hast jedoch noch sehr viele Lücken, die du erst ausmerzen solltest.
Du scheinst mir nicht sehr einsichtig zu sein. Eigentlich solltest du zu dir selbst sagen, dass du nicht oder nur wenig gelernt hast und es dann das nächste mal besser machen. Daher mein Tip: sehe das als Chance. Mach die nächste Prüfung und dann rock das Ding mit einer zwei. Das bringt dich nicht nur besser ins Arbeitsleben, sondern bringt dich auch persönlich voran. Die beste Art zu lernen ist außerdem, die Prüfungen der Vorjahre durchzugehen. Die Aufgaben sind sehr ähnlich. Und dann wüsstest du auch, dass ständig ein bisschen heirvon, ein bisschen davon dran kommt und dich beim Lernen darauf konzentrieren.

Der Arbeitgeber braucht aber Möglichkeiten, dich zu bewerten und da können deine Antworten alleine nicht die Lösung sein, da man sich selbst nie objektiv einschätzt. Natürlich bist zu zuverlässig, natürlich arbeitest du ordentlich und bist pünktlich. Aber das sagt jeder von sich. Die Unterschiede zwischen den Bewerbern werden genau durch "Quatschfragen" und den Reaktionen aus diesen herausgefiltert.
Und sorry, aber da verlierst du, wenn du nicht bereit bist, dich darauf einzulassen. Denn Offenheit gegenüber etwas Neuem und Unbekannten ist durchaus eine Stärke - gerade wenn es um Führungsqualitäten geht.
 

Wirtschaftsinformatik hat nur bedingt etwas mit "Informatik" zu tun. Die Wirtschaftsinformatik nutzt die Informatik als Hilfe, um Probleme in der BWL zu lösen, welche die BWL alleine nicht lösen kann. Informatik dagegen ist die Wissenschaft, wie man systematisch (digitale) Informationen bearbeiten kann. Die Problemstellung und -lösung kommt dabei aus dem digitalen Bereich (zB wie kann man zwei Floats miteinander berechnen, ohne, dass das Ergebnis allzu krumm ist). Diese unteren Schichten braucht Bindestrich-Informatiker eigentlich gar nicht (oder nur grob) zu interessieren. Und daher kommt auch die Unterscheidung zwischen Wissenschaften und angewandten Wissenschaften, wodurch resultiert, dass Informatik an der Universitäten angeboten wird und Wirtschatfs/Medien/...-Informatik an Hochschulen für angewandte Wissenschaften (Universities of applied Sciences).
B2T:
Eine längere Fort- oder Weiterbildung, Studium usw. kann durchaus die Beziehung und Familie belasten. Ich habe es schon öfter mitbekommen, dass die Bez. auf eine harte Probe gestellt wurde und dabei ging es gar nicht unbedingt um ein Studium, sondern auch Techniker, Meister, Fachwirt usw. neben dem Beruf schränkt die Freizeit, die man für die Familie benötigt, dann doch ein. Unmöglich ist es natürlich nicht, aber man sollte das mit der Familie absprechen und diese hinter einem stehen. Und selbst dann gibt es genügend Konfliktpotential. Natürlich ist es machbar, aber es ist auch mit Aufwand verbunden, der nicht unterschätzt werden sollte (ein, zwei Stunden die Woche reicht definitiv nicht für ein Studium aus). 

Also er funktioniert wieder einwandfrei. Ich hatte gestern das Bios resetet und habe dann erstmal den PC ohne Graka usw. angeschlossen --> Ging. Dann habe ich Schritt für Schritt mehr Sachen angeklemmt und am Ende ging dann alles, vielen Dank für eure Hilfe!
VG, Deadpool

Generell finde ich, das viele Dinge im Bereich Ausbildung, Job und Studium in Amerika z.B. besser voneinander abgegrenzt und durchdacht sind, wie hierzulande. Gerade was das Studium seit Bachelor, Master und Co. angeht. Hierzulande versteht da gefühlt jeder was anderes drunter, wofür was gedacht ist und womit das vergleichbar ist und dort hat man das Gefühl, dass zumindest diese Sachen im Schnitt deutlich besser geregelt sind.
Hinzu kommt, dass die Wirtschaft immer mehr ein Studium fordert auch für Jobs, wo eigentlich eine Ausbildung reichen würde, was gerade den Unterschied Ausbildung und Studium weiter verwässter.
...
Deswegen bezeichnet man im Englischen Wirtschaftsinformatik eben auch nicht als -Informatik, sondern als eigenständiges Fach, was es ja auch ist. Hätte ich das damals so in der drastischen Form gewusst, hätte ich was anderes studiert, weil ich tatsächlich eher Informatik machen wollte, mit nen bissel BWL und nicht 50:50. Klar, kannste Dir vorher den Stundenplan anschauen, aber mehr auch nicht. Und da finde ich den Titel hierzulande schon verwirrend, bis - streng genommen - falsch.  

Wirtschaftsinformatik hat nur bedingt etwas mit "Informatik" zu tun. Die Wirtschaftsinformatik nutzt die Informatik als Hilfe, um Probleme in der BWL zu lösen, welche die BWL alleine nicht lösen kann. Informatik dagegen ist die Wissenschaft, wie man systematisch (digitale) Informationen bearbeiten kann. Die Problemstellung und -lösung kommt dabei aus dem digitalen Bereich (zB wie kann man zwei Floats miteinander berechnen, ohne, dass das Ergebnis allzu krumm ist). Diese unteren Schichten braucht Bindestrich-Informatiker eigentlich gar nicht (oder nur grob) zu interessieren. Und daher kommt auch die Unterscheidung zwischen Wissenschaften und angewandten Wissenschaften, wodurch resultiert, dass Informatik an der Universitäten angeboten wird und Wirtschatfs/Medien/...-Informatik an Hochschulen für angewandte Wissenschaften (Universities of applied Sciences).
B2T:
Eine längere Fort- oder Weiterbildung, Studium usw. kann durchaus die Beziehung und Familie belasten. Ich habe es schon öfter mitbekommen, dass die Bez. auf eine harte Probe gestellt wurde und dabei ging es gar nicht unbedingt um ein Studium, sondern auch Techniker, Meister, Fachwirt usw. neben dem Beruf schränkt die Freizeit, die man für die Familie benötigt, dann doch ein. Unmöglich ist es natürlich nicht, aber man sollte das mit der Familie absprechen und diese hinter einem stehen. Und selbst dann gibt es genügend Konfliktpotential. Natürlich ist es machbar, aber es ist auch mit Aufwand verbunden, der nicht unterschätzt werden sollte (ein, zwei Stunden die Woche reicht definitiv nicht für ein Studium aus). 

Hallo Gaukler,
Ich habe respekt davor. Wirklich! Bei mir lief auch nicht alles immer geradlinig, deshalb weiß ich, dass man dadurch auch in einer gewissen weiße andere Expertisen oder Lebenserfahrungen sammeln kann. Dennoch, kann man von niemandem erwarten (schon gar nich von einem Personalverantwortlichen), dass er großes Verständnis für eine Situation hat, die er gar nicht kennt. Denn deine persönlichen Probleme gehören definitiv nicht in ein Bewerbungsschreiben. Wenn du dann aber zum Gespräch eingeladen wirst, solltest du begründen können, warum wie was gewesen ist, dass du die Krise überwunden hast und gestärkt daraus hervorgegangen bist. Ist auf jeden fall besser, als zum Beispiel Verständnis für deine Situation zu erwarten.
Also mein Tip: bewerbe dich, lass dein Schreiben und Lebenslauf von uns hier checken. Du solltest dabei keine Angst haben, sondern Selbstbewusstsein zeigen und dann wird es schon werden. Ich habe einmal ein Bewerbungsverfahren bei der Suche nach einem Azubi begleitet, da gab es sehr viele schlechte Bewerber, die weder die Firma noch den Ansprechpartner richtig schreiben, die gar keine Zeugnisse beilegen, die keine Satzzeichen machen usw. Wenn du nicht auch so grobe Fehler machst, bin ich mir sicher, dass du zum Gespräch eingeladen wirst. 
Viel Erfolg

Da ich einigen Kommilitonen Nachhilfe gebe (die zum Teil gar nichts mti IT studieren, sondern einfach das Modul irgendwie bestehen müssen), habe ich inzwischen einiges an Erfahrung, woran es hackt:
1. Grundlagen (1) 
Ganz häufig ist das Problem, dass sie zwar "irgendwie wissen", was Variablen, Klassen, Methoden usw. sind, aber nicht, wofür man die anwendet. Das muss einfach sitzen. Zum Beispiel kommen viele überhaupt nicht auf die Idee, hier und da einfach eine Variable zu deklarieren, in der irgendwas zwischen gespeichert wird. Dieses Denken muss sich auch erst entwickeln und darum ist es wichtig, damit rumzuspielen. Zum Beispiel, alle möglichen Operationen auf Integer anwenden, auf Floats, auf Strings, diese zu kombinieren, in ne neue Variable reinzuschmeißen usw. Damit man einfach ein Gefühl dafür kriegt, was überhaupt möglich ist. Und dann kommt irgendwann das Denken "oh, da mach ich mir ne neue Methode, schmeiß den Rückgabewert in ne Variable und arbeite damit weiter". Aber dafür muss man nicht "lesen, lesen, lesen" sondern einfach "machen, machen, machen".
2. Grundlagen (2)
Was auf jeden Fall sitzen muss sind Datentypen (primitive Datentypen, Arrays), Verzweigungen (IF, If-Else, If-Else if-Else, Switch-Case), Schleifen (while, do-while, for, foreach). Ich merke immer wieder, dass viele selbst nach einem halben Jahr Softwareentwicklung einfach nicht auf die Idee kommen, zwei Bedingungen in ein If zu stecken oder eine Schleife rückwärts laufen zu lassen. Wieso nicht? Der PC macht, was der Programmierer will (wenn der das richtig angibt)
3. Aufgaben verstehen
Mit Grundlagen 1 und 2 kann man schon sehr sehr viel machen. Zum Beispiel diese ganzen typischen Aufgaben wie z.B. "finde die größte Zahl in einem Array", "ermittle den Durchschnitt in einem Array", "gebe einen Text rückwärts aus", "implementiere ein Zahlenraten" usw., also die typischen Aufgaben für einen Anfänger. Diese Aufgaben muss man irgendwie vom Text in Code umwandeln. Ganz oft, gibt der Text aber auch Hinweise darüber, was man machen muss. Zum Beispiel: "der User soll eine Zufällige Zahl raten. Solange die Zahl nicht erraten wurde, soll 'Leider falsch... Nochmal raten' ausgegeben werden. Ansonsten, soll 'Super, du hast die Zahl erraten" ausgegeben werden. Gebe zusätzlich aus, wie viele Versuche der User benötigt hat". Darin steckt schon sehr viel, was man machen muss:
Der User soll eine Zufällige Zahl raten: Super, dann steck ich eine Zahl in einen Integer! Solange blablablabla...: Super! Solange irgendwas gemacht wird, ist immer eine Schleife (genauso wie "für alle..."). Wenn dies.... ansonsten...: Ahhhh, eine If-Verzwiegung! Wie viele Versuche: Ah, ich muss die Versuche irgendwo speichern. Ah, wie wärs mit nem Integer, den man hoch zählt, wenn die Zahl nicht getroffen wurde! Mit der Zeit entwickelt sich dann das "Denken in Code" und sobald das passiert ist, ist es egal, ob ich in einer Schleife jeden Zweiten Wert aus einem Array auslese, oder der Holzfäller jeden zweiten Baum fällt. Irgendwann entwickelt sich das schon.
4. Nicht das große Ganze sehen
In Punkt 3 habe ich eine Aufgabe, die vielleicht am Anfang komplex erscheinen kann, in viele kleinere Schritte zerlegt. Aber genau darum geht es: nicht das große Ganze sehen und nicht wissen, was zu tun ist, sondern Schritt für Schritt das Problem lösen. Zum Beispiel, erst einmal eine Zufallszahl erzeugen und ausgeben. Funktioniert? Wunderbar, dann kanns ja weiter gehen. Dann eine Zahl einlesen. Cool, klappt ja auch! Dann die Zahl mit der Zufallszahl vergleichen. Geil, gar kein Problem. Dann eine Schleife drumrum basteln. Oh, jetzt will er immer eine Eingabe. Wie unterbreche ich jetzt die Schleife, wenn die Eingabe stimmt? Was gabs da nochmal? Ah, genau, break. Perfekt, funktioniert. Nun noch ne Variable die die Fehlschläge zählt, die am Ende mit ausgeben und fertig. Cool, läuft. Und dann macht es auch Spaß
5. Dann erst komplexere Dinge machen
Sobald man Punkt 3 beherrscht, kann man sich komplexeren Dingen zuwenden, wie zB Klassen, Designpattern usw. 
6. Üben, üben, üben
Egal wie gut ein Programmierer ist, er kann immer noch was lernen. Aber die, die das Jahrelang machen, haben jeden Fehler zehn, zwanzig, hundert mal gemacht, bevor sie sich weiter entwickelt haben. Programmieren lernen hat (leider) nicht immer eine steile Lernkurve, sondern ist manchmal auch einfach ätzend. Aber wenn man dann nach drei Stunden endlich ein Problem gelöst hat, darf man auch mal stolz auf sich sein  

Da ich einigen Kommilitonen Nachhilfe gebe (die zum Teil gar nichts mti IT studieren, sondern einfach das Modul irgendwie bestehen müssen), habe ich inzwischen einiges an Erfahrung, woran es hackt:
1. Grundlagen (1) 
Ganz häufig ist das Problem, dass sie zwar "irgendwie wissen", was Variablen, Klassen, Methoden usw. sind, aber nicht, wofür man die anwendet. Das muss einfach sitzen. Zum Beispiel kommen viele überhaupt nicht auf die Idee, hier und da einfach eine Variable zu deklarieren, in der irgendwas zwischen gespeichert wird. Dieses Denken muss sich auch erst entwickeln und darum ist es wichtig, damit rumzuspielen. Zum Beispiel, alle möglichen Operationen auf Integer anwenden, auf Floats, auf Strings, diese zu kombinieren, in ne neue Variable reinzuschmeißen usw. Damit man einfach ein Gefühl dafür kriegt, was überhaupt möglich ist. Und dann kommt irgendwann das Denken "oh, da mach ich mir ne neue Methode, schmeiß den Rückgabewert in ne Variable und arbeite damit weiter". Aber dafür muss man nicht "lesen, lesen, lesen" sondern einfach "machen, machen, machen".
2. Grundlagen (2)
Was auf jeden Fall sitzen muss sind Datentypen (primitive Datentypen, Arrays), Verzweigungen (IF, If-Else, If-Else if-Else, Switch-Case), Schleifen (while, do-while, for, foreach). Ich merke immer wieder, dass viele selbst nach einem halben Jahr Softwareentwicklung einfach nicht auf die Idee kommen, zwei Bedingungen in ein If zu stecken oder eine Schleife rückwärts laufen zu lassen. Wieso nicht? Der PC macht, was der Programmierer will (wenn der das richtig angibt)
3. Aufgaben verstehen
Mit Grundlagen 1 und 2 kann man schon sehr sehr viel machen. Zum Beispiel diese ganzen typischen Aufgaben wie z.B. "finde die größte Zahl in einem Array", "ermittle den Durchschnitt in einem Array", "gebe einen Text rückwärts aus", "implementiere ein Zahlenraten" usw., also die typischen Aufgaben für einen Anfänger. Diese Aufgaben muss man irgendwie vom Text in Code umwandeln. Ganz oft, gibt der Text aber auch Hinweise darüber, was man machen muss. Zum Beispiel: "der User soll eine Zufällige Zahl raten. Solange die Zahl nicht erraten wurde, soll 'Leider falsch... Nochmal raten' ausgegeben werden. Ansonsten, soll 'Super, du hast die Zahl erraten" ausgegeben werden. Gebe zusätzlich aus, wie viele Versuche der User benötigt hat". Darin steckt schon sehr viel, was man machen muss:
Der User soll eine Zufällige Zahl raten: Super, dann steck ich eine Zahl in einen Integer! Solange blablablabla...: Super! Solange irgendwas gemacht wird, ist immer eine Schleife (genauso wie "für alle..."). Wenn dies.... ansonsten...: Ahhhh, eine If-Verzwiegung! Wie viele Versuche: Ah, ich muss die Versuche irgendwo speichern. Ah, wie wärs mit nem Integer, den man hoch zählt, wenn die Zahl nicht getroffen wurde! Mit der Zeit entwickelt sich dann das "Denken in Code" und sobald das passiert ist, ist es egal, ob ich in einer Schleife jeden Zweiten Wert aus einem Array auslese, oder der Holzfäller jeden zweiten Baum fällt. Irgendwann entwickelt sich das schon.
4. Nicht das große Ganze sehen
In Punkt 3 habe ich eine Aufgabe, die vielleicht am Anfang komplex erscheinen kann, in viele kleinere Schritte zerlegt. Aber genau darum geht es: nicht das große Ganze sehen und nicht wissen, was zu tun ist, sondern Schritt für Schritt das Problem lösen. Zum Beispiel, erst einmal eine Zufallszahl erzeugen und ausgeben. Funktioniert? Wunderbar, dann kanns ja weiter gehen. Dann eine Zahl einlesen. Cool, klappt ja auch! Dann die Zahl mit der Zufallszahl vergleichen. Geil, gar kein Problem. Dann eine Schleife drumrum basteln. Oh, jetzt will er immer eine Eingabe. Wie unterbreche ich jetzt die Schleife, wenn die Eingabe stimmt? Was gabs da nochmal? Ah, genau, break. Perfekt, funktioniert. Nun noch ne Variable die die Fehlschläge zählt, die am Ende mit ausgeben und fertig. Cool, läuft. Und dann macht es auch Spaß
5. Dann erst komplexere Dinge machen
Sobald man Punkt 3 beherrscht, kann man sich komplexeren Dingen zuwenden, wie zB Klassen, Designpattern usw. 
6. Üben, üben, üben
Egal wie gut ein Programmierer ist, er kann immer noch was lernen. Aber die, die das Jahrelang machen, haben jeden Fehler zehn, zwanzig, hundert mal gemacht, bevor sie sich weiter entwickelt haben. Programmieren lernen hat (leider) nicht immer eine steile Lernkurve, sondern ist manchmal auch einfach ätzend. Aber wenn man dann nach drei Stunden endlich ein Problem gelöst hat, darf man auch mal stolz auf sich sein  

Da ich einigen Kommilitonen Nachhilfe gebe (die zum Teil gar nichts mti IT studieren, sondern einfach das Modul irgendwie bestehen müssen), habe ich inzwischen einiges an Erfahrung, woran es hackt:
1. Grundlagen (1) 
Ganz häufig ist das Problem, dass sie zwar "irgendwie wissen", was Variablen, Klassen, Methoden usw. sind, aber nicht, wofür man die anwendet. Das muss einfach sitzen. Zum Beispiel kommen viele überhaupt nicht auf die Idee, hier und da einfach eine Variable zu deklarieren, in der irgendwas zwischen gespeichert wird. Dieses Denken muss sich auch erst entwickeln und darum ist es wichtig, damit rumzuspielen. Zum Beispiel, alle möglichen Operationen auf Integer anwenden, auf Floats, auf Strings, diese zu kombinieren, in ne neue Variable reinzuschmeißen usw. Damit man einfach ein Gefühl dafür kriegt, was überhaupt möglich ist. Und dann kommt irgendwann das Denken "oh, da mach ich mir ne neue Methode, schmeiß den Rückgabewert in ne Variable und arbeite damit weiter". Aber dafür muss man nicht "lesen, lesen, lesen" sondern einfach "machen, machen, machen".
2. Grundlagen (2)
Was auf jeden Fall sitzen muss sind Datentypen (primitive Datentypen, Arrays), Verzweigungen (IF, If-Else, If-Else if-Else, Switch-Case), Schleifen (while, do-while, for, foreach). Ich merke immer wieder, dass viele selbst nach einem halben Jahr Softwareentwicklung einfach nicht auf die Idee kommen, zwei Bedingungen in ein If zu stecken oder eine Schleife rückwärts laufen zu lassen. Wieso nicht? Der PC macht, was der Programmierer will (wenn der das richtig angibt)
3. Aufgaben verstehen
Mit Grundlagen 1 und 2 kann man schon sehr sehr viel machen. Zum Beispiel diese ganzen typischen Aufgaben wie z.B. "finde die größte Zahl in einem Array", "ermittle den Durchschnitt in einem Array", "gebe einen Text rückwärts aus", "implementiere ein Zahlenraten" usw., also die typischen Aufgaben für einen Anfänger. Diese Aufgaben muss man irgendwie vom Text in Code umwandeln. Ganz oft, gibt der Text aber auch Hinweise darüber, was man machen muss. Zum Beispiel: "der User soll eine Zufällige Zahl raten. Solange die Zahl nicht erraten wurde, soll 'Leider falsch... Nochmal raten' ausgegeben werden. Ansonsten, soll 'Super, du hast die Zahl erraten" ausgegeben werden. Gebe zusätzlich aus, wie viele Versuche der User benötigt hat". Darin steckt schon sehr viel, was man machen muss:
Der User soll eine Zufällige Zahl raten: Super, dann steck ich eine Zahl in einen Integer! Solange blablablabla...: Super! Solange irgendwas gemacht wird, ist immer eine Schleife (genauso wie "für alle..."). Wenn dies.... ansonsten...: Ahhhh, eine If-Verzwiegung! Wie viele Versuche: Ah, ich muss die Versuche irgendwo speichern. Ah, wie wärs mit nem Integer, den man hoch zählt, wenn die Zahl nicht getroffen wurde! Mit der Zeit entwickelt sich dann das "Denken in Code" und sobald das passiert ist, ist es egal, ob ich in einer Schleife jeden Zweiten Wert aus einem Array auslese, oder der Holzfäller jeden zweiten Baum fällt. Irgendwann entwickelt sich das schon.
4. Nicht das große Ganze sehen
In Punkt 3 habe ich eine Aufgabe, die vielleicht am Anfang komplex erscheinen kann, in viele kleinere Schritte zerlegt. Aber genau darum geht es: nicht das große Ganze sehen und nicht wissen, was zu tun ist, sondern Schritt für Schritt das Problem lösen. Zum Beispiel, erst einmal eine Zufallszahl erzeugen und ausgeben. Funktioniert? Wunderbar, dann kanns ja weiter gehen. Dann eine Zahl einlesen. Cool, klappt ja auch! Dann die Zahl mit der Zufallszahl vergleichen. Geil, gar kein Problem. Dann eine Schleife drumrum basteln. Oh, jetzt will er immer eine Eingabe. Wie unterbreche ich jetzt die Schleife, wenn die Eingabe stimmt? Was gabs da nochmal? Ah, genau, break. Perfekt, funktioniert. Nun noch ne Variable die die Fehlschläge zählt, die am Ende mit ausgeben und fertig. Cool, läuft. Und dann macht es auch Spaß
5. Dann erst komplexere Dinge machen
Sobald man Punkt 3 beherrscht, kann man sich komplexeren Dingen zuwenden, wie zB Klassen, Designpattern usw. 
6. Üben, üben, üben
Egal wie gut ein Programmierer ist, er kann immer noch was lernen. Aber die, die das Jahrelang machen, haben jeden Fehler zehn, zwanzig, hundert mal gemacht, bevor sie sich weiter entwickelt haben. Programmieren lernen hat (leider) nicht immer eine steile Lernkurve, sondern ist manchmal auch einfach ätzend. Aber wenn man dann nach drei Stunden endlich ein Problem gelöst hat, darf man auch mal stolz auf sich sein  

Da ich einigen Kommilitonen Nachhilfe gebe (die zum Teil gar nichts mti IT studieren, sondern einfach das Modul irgendwie bestehen müssen), habe ich inzwischen einiges an Erfahrung, woran es hackt:
1. Grundlagen (1) 
Ganz häufig ist das Problem, dass sie zwar "irgendwie wissen", was Variablen, Klassen, Methoden usw. sind, aber nicht, wofür man die anwendet. Das muss einfach sitzen. Zum Beispiel kommen viele überhaupt nicht auf die Idee, hier und da einfach eine Variable zu deklarieren, in der irgendwas zwischen gespeichert wird. Dieses Denken muss sich auch erst entwickeln und darum ist es wichtig, damit rumzuspielen. Zum Beispiel, alle möglichen Operationen auf Integer anwenden, auf Floats, auf Strings, diese zu kombinieren, in ne neue Variable reinzuschmeißen usw. Damit man einfach ein Gefühl dafür kriegt, was überhaupt möglich ist. Und dann kommt irgendwann das Denken "oh, da mach ich mir ne neue Methode, schmeiß den Rückgabewert in ne Variable und arbeite damit weiter". Aber dafür muss man nicht "lesen, lesen, lesen" sondern einfach "machen, machen, machen".
2. Grundlagen (2)
Was auf jeden Fall sitzen muss sind Datentypen (primitive Datentypen, Arrays), Verzweigungen (IF, If-Else, If-Else if-Else, Switch-Case), Schleifen (while, do-while, for, foreach). Ich merke immer wieder, dass viele selbst nach einem halben Jahr Softwareentwicklung einfach nicht auf die Idee kommen, zwei Bedingungen in ein If zu stecken oder eine Schleife rückwärts laufen zu lassen. Wieso nicht? Der PC macht, was der Programmierer will (wenn der das richtig angibt)
3. Aufgaben verstehen
Mit Grundlagen 1 und 2 kann man schon sehr sehr viel machen. Zum Beispiel diese ganzen typischen Aufgaben wie z.B. "finde die größte Zahl in einem Array", "ermittle den Durchschnitt in einem Array", "gebe einen Text rückwärts aus", "implementiere ein Zahlenraten" usw., also die typischen Aufgaben für einen Anfänger. Diese Aufgaben muss man irgendwie vom Text in Code umwandeln. Ganz oft, gibt der Text aber auch Hinweise darüber, was man machen muss. Zum Beispiel: "der User soll eine Zufällige Zahl raten. Solange die Zahl nicht erraten wurde, soll 'Leider falsch... Nochmal raten' ausgegeben werden. Ansonsten, soll 'Super, du hast die Zahl erraten" ausgegeben werden. Gebe zusätzlich aus, wie viele Versuche der User benötigt hat". Darin steckt schon sehr viel, was man machen muss:
Der User soll eine Zufällige Zahl raten: Super, dann steck ich eine Zahl in einen Integer! Solange blablablabla...: Super! Solange irgendwas gemacht wird, ist immer eine Schleife (genauso wie "für alle..."). Wenn dies.... ansonsten...: Ahhhh, eine If-Verzwiegung! Wie viele Versuche: Ah, ich muss die Versuche irgendwo speichern. Ah, wie wärs mit nem Integer, den man hoch zählt, wenn die Zahl nicht getroffen wurde! Mit der Zeit entwickelt sich dann das "Denken in Code" und sobald das passiert ist, ist es egal, ob ich in einer Schleife jeden Zweiten Wert aus einem Array auslese, oder der Holzfäller jeden zweiten Baum fällt. Irgendwann entwickelt sich das schon.
4. Nicht das große Ganze sehen
In Punkt 3 habe ich eine Aufgabe, die vielleicht am Anfang komplex erscheinen kann, in viele kleinere Schritte zerlegt. Aber genau darum geht es: nicht das große Ganze sehen und nicht wissen, was zu tun ist, sondern Schritt für Schritt das Problem lösen. Zum Beispiel, erst einmal eine Zufallszahl erzeugen und ausgeben. Funktioniert? Wunderbar, dann kanns ja weiter gehen. Dann eine Zahl einlesen. Cool, klappt ja auch! Dann die Zahl mit der Zufallszahl vergleichen. Geil, gar kein Problem. Dann eine Schleife drumrum basteln. Oh, jetzt will er immer eine Eingabe. Wie unterbreche ich jetzt die Schleife, wenn die Eingabe stimmt? Was gabs da nochmal? Ah, genau, break. Perfekt, funktioniert. Nun noch ne Variable die die Fehlschläge zählt, die am Ende mit ausgeben und fertig. Cool, läuft. Und dann macht es auch Spaß
5. Dann erst komplexere Dinge machen
Sobald man Punkt 3 beherrscht, kann man sich komplexeren Dingen zuwenden, wie zB Klassen, Designpattern usw. 
6. Üben, üben, üben
Egal wie gut ein Programmierer ist, er kann immer noch was lernen. Aber die, die das Jahrelang machen, haben jeden Fehler zehn, zwanzig, hundert mal gemacht, bevor sie sich weiter entwickelt haben. Programmieren lernen hat (leider) nicht immer eine steile Lernkurve, sondern ist manchmal auch einfach ätzend. Aber wenn man dann nach drei Stunden endlich ein Problem gelöst hat, darf man auch mal stolz auf sich sein  

Ich mag ja eigentlich unkenventionelle Gedankengänge. Aber die müssen eben auch angebracht sein und zum Kontext passen. Im Grunde richtet sich die Bewerbung an mehrere Personen, bzw. mehrere verschiedene Personen (Sekretäre/-innen, HR, HR-Leitung, Abteilungsleiter, ...) lesen darüber und treffen eine Auswahl an Favoriten, die für das weitere Bewerbungsverfahren in Frage kommen.
Andererseits ist es immer auch nicht schlecht, wenn man sich im Bewerbungsschreiben hervorheben kann. Aber in Deutschland ist man im Geschäftsleben eher noch konventienell oder anders ausgedrückt, wenn 99% "Sehr geehrte Damen und Herren" schreiben, und 1% nicht, dann ist man eher bei den 99% auf der sicheren Seite. Es hängt auch immer davon ab, wo und als was man sich bewirbt. Wenn ich mich jetzt bei ner Werbeagentur bewerbe, ist meine Sprache sicherlich eine andere, als wenn ich mich bei einer Bank bewerbe. Aber das muss man auch entsprechend können, um nicht zu extrem in eine falsche Richtung abzutriften.
Und im Chinesischen ist es wieder anders... Mach nicht den fehler und versuche, kulturelle Gewohnheiten einzudeutschen. In England ist man ab dem zweiten Kontakt auch bei "Dear Anton, ..." während man im Deutschen abwartet, bis die/der höher gestellte das Du anbietet und man "Hallo Anton..." schreiben kann. Das ist aber kein Grund, bei uns in Deutschland selber das Du zu verwenden oder vom "Sehr geehrter Herr Mustermann" abzuweichen (so spießig das auch sein mag). Im Geschäftsleben muss man einfach gewisse Regeln beachten, genau so wie man im Privatleben eine gewisse Nettiquette hat.