Ahua.
Zunächst einmal ein wenig Begriffsklärung : Programmierer/in/um ist nach dem üblichen Verständnis derdiedasjenige, wo eine von Anderen erstellte konkrete Vorgabe (in Prosa) in eine Programmiersprache umsetzt, d.h. codiert. Das ist eine recht eng gefasste Aufgabenstellung.
Beispiel : Aus einem Datenbestand der fakturierten Verkäufe eines Unternehmens soll eine Liste mit den Umsätzen nach Postleitzahl-Gebieten generiert werden. Die Vorgabe an den Programmierer lautet dann : Erzeugen Sie aus der Datei HAUMICH.TOT eine Liste, in der die Umsätze nach den ersten zwei Stellen der Postleitzahl, aufsteigend sortiert, subsumiert dargestellt werden. Die Liste soll mittels Laserdrucker auf DIN A4 quer ausgedruckt werden; Seitenwechsel nach der ersten Stelle der PLZ; Überschrift folgendermaßen blabla …
Ein Entwickler/Softwaregestalter/Rabimmelrabumm (es gibt mehr Bezeichnungen dafür als schwarze Katzen in der Westschweiz) dagegen steigt beim Kunden (intern oder extern) in die Prozessanalyse ein und wird aus dem Gefasel des Kunden „Ich brauche eine Liste der monatlichen Umsätze nach Postleitzahl“ eine Anforderung der obigen Art erzeugen. Diese setzt er selbst um oder vergibt die Aufgabe, wie im vorigen Absatz, an einen Programmierer. Nach erfolgter Codierung und Systemintegration wird das Programm beim Kunden eingesetzt und von diesem abgenommen. Diese Aufgabe ist im Allgemeinen um einiges anspruchsvoller als das reine Codieren.
Für das Codieren benötigst Du die Fähigkeit, die Programmanforderung von oben in eine Sprache umzusetzen; d.h. Du solltest die Sprachstrukturen kennen und auf in Prosa gelöste Probleme anwenden können. Hierfür brauchst Du die Fähigkeit zum sinnerfassenden Lesen und die Kenntnis der jeweiligen Programmiersprache bzw. Systemumgebung. Das heißt natürlich in letzter Konsequenz, dass jeder x-beliebige Trottel Programmierer sein kann … deshalb ist das auch kein Ausbildungsberuf.
Als Entwicklerpipapo steht die Fähigkeit im Vordergrund, Prozesse im Unternehmen verstehen und in einen DV- Ablauf umwandeln zu können. Das Wichtigste dabei ist die Fähigkeit zum analytischen Denken, um innerhalb vernünftiger Zeit das Problem verstehen und selbst beschreiben zu können - dessen grundsätzliche Lösbarkeit sei hier einmal vorausgesetzt. Da die Aufgabe normalerweise nicht so simpel ist wie in meinem Beispiel, kann Wissen um unternehmensinterne Strukturen und Prozesse absolut nicht schaden.
Ein wenig ist diese Tätigkeit mit der eines Rechtsanwalts zu vergleichen, der sich ebenfalls innerhalb kurzer Zeit Insiderwissen über einen Fall erwerben muss. Er wird dieses zu großen Teilen recht schnell zurückwissen, i.e. vergessen, können. Zum Zeitpunkt der Realisierung eines Programms ist Detailwissen für den Entwickler unabdingbar, später aber nicht mehr „on-line“ vorhanden (NB : deswegen ist Dokumentation auch kein Selbstzweck).
Aus meiner Berufspraxis noch ein Beispiel dazu : Ich bin gelernter Koofmich und Seiteneinsteiger mit inzwischen gut 25 Jahren IT auf dem Buckel. Letztes Jahr hatte ich die dankbare Aufgabe, ein Pascal-Programm von Anno Kawumm, das in keiner Weise dokumentiert war, auf unsere heutige Umgebung zu transferieren, also völlig neu zu entwickeln. Es handelte sich dabei um Messdatenberechnung für evolventenverzahnte Wellen und Bohrungen; hochtechnisch und mathematisch so komplex, dass ich da zunächst reinguckte wie die Sau ins Uhrwerk. Die eigentliche Arbeit bestand also zunächst darin, mir von den Fachleuten die Zusammenhänge so erklären zu lassen, dass ich verstand, was mathematisch abzulaufen hatte und dies in ein System verwandeln konnte. Eine echte Herausforderung für den Kunden wie für mich 
Das gesammelte Messtechnik-Fachwissen in meinen armen Schädel zu bekommen, hätte in diesem Leben nicht mehr funktioniert; also beschränkte sich die Wissensvermittlung auf die reine Prozessbeschreibung. Das Codieren und Dokumentieren nahm grob geschätzt 25-30% der gesamten aufgewendeten Arbeitszeit in Anspruch - viel wesentlicher war das Verstehen des Problems.
Uff, sprach Winnetou, biss sich ein Loch in den Bauch und verschwand herinnen. Sinn und Zweck dieses langen Sumses war der Versuch, Dir zu erklären, dass das eigentliche Programmieren, also Hock&Hack, nur ein relativ kleiner Bestandteil der Arbeit bei der Softwareentwicklung ist.
Eine oder meinetwegen auch zwölf Programmiersprachen zu lernen, wird Dich nicht dazu befähigen, einen halbwegs anspruchsvollen und auch einträglichen Job zu finden. Du solltest entweder den akademischen Weg wählen (Informatik), wo Dir die Methodik der Prozessanalyse, Algorithmenerstellung und ganz nebenbei auch die eine oder andere Sprache beigebogen werden, oder aber über eine Ingenieurslaufbahn nachdenken (Kaufmannswissen ist für einen Techniker leichter zu erwerben als andersrum!), wobei Du da zur Genüge mit Computern zu tun bekommen wirst. Wichtig ist, neben der Fähigkeit zum analytischen Denken, vor allem das Interesse, Kundenprobleme zu verstehen und zu lösen. Der Blechheini kommt irgendwann kurz vor Schluss der Kette, als ein Arbeitsmittel von vielen. Kommunikationsfähigkeiten, und zwar auf der menschlichen Seite, sind da viel gefragter als Shakespeare auf Hexadezimal rezitieren zu können.
Wenn Du Deinen Schwerpunkt dagegen auf der Computerecke siehst, also lieber mit dem PC arbeitest als mit Leuten in Projekten obskure Fragestellungen abzuarbeiten, wirst Du als „Programmierer“ (Entwickler) eher nicht glücklich werden; solche Leute sind eher in der Systemadministration/-analyse zu Hause. Oder bei Wäwäwä als Webseitenverwurster 
Das solls erst einmal gewesen sein; bei Bedarf jammere ich Dir gern noch mehr aus meinem verfehlten Leben vor 
Hol Dir ein Sternchen für Deine Geduld, falls Du bis hierhin durchgehalten hast.
Gruß Eillicht zu Vensre