kan jag bli programmerare??

Jag tror inte det är något större hinder att vara 30+ och ny examinerad inom IT. och inte att vara kvinna heller för den delen, det är nog snarare en fördel eftersom de flesta kontor jag varit i kontakt med vill försöka få en blandad sammansättning.

Webutveckling är däremot inget jag direkt klassificerar som programmering och kräver minimal förståelse av systemuppbyggnad osv. Jag vågar inte svara på hur arbetsmarknaden ser ut där men det jag däremot vet är att de allra flesta webutvecklingsföretag är oftast 2-5 personers företag och det kan ha både för och nackdelar.

Att börja programmera helt från början är nog lättast att göra i något ganska begränsat språk, att lära sig grunder i programkods flöde osv kan man göra i princip vilket språk som helst.

Det jag personligen tycker är väldigt synd och som jag märker på många relativt nyexade studenter vi tagit in på mitt jobb är att de lär sig inte hur programkoden interagerar med arkitekturen utan utgår från devisen att JVM:en / CLR:en (Javas respektive .NETs virtuella maskiner) osv tar hand om allt detta. 
Det tänket fungerar så länge man bara skriver program utan att bry sig minsta om prestanda och minnesfootprint.

Jag tror personligen det är enormt nyttigt att man börjar lätt sedan dyker ner på djupet för att sedan gå uppåt i abstraktionsnivåer igen, vill man tro att (just-in-time) kompilatorer är magiska konstrukt som kan räkna ut vad det är du försöker göra så kan man ju fortsätta tro detta. Men personer som förstår varför och hur något beter sig på det sätt det gör vet jag är enormt eftertraktade. 

Sen är det väldigt bra om man lär sig använda UN*X system eftersom det i 99% av fallen är vad som programkoden kommer köras på i slutändan. Slutanvändarprodukter som Windows program osv är väldigt liten marknad om du ser till antalet företag som jobbar med mjukvaruutveckling.

Är benägen att hålla med, Java som språk är definitivt inte svårare än något annat. 

Visst till skillnad från javascript så har det typade variabler. Att java har tusentals bibliotek däremot är sant men man är ju inte tvungen att använda Spring, Hibernate osv bara för man skriver i Java.

Håller med,

Och framförallt tycker jag att det är fullkomligt idiotiskt att utgå från ett språk som är event baserat (tillskillnad från de flesta "riktiga" språk som har tydliga ingångsmetoder) och tillåter att man cowboy kodar hur mycket man vill.

Språket har katastrofalt dåliga verktyg för felsökning (debugging alltså) och som alla tolkade språk så hittar man sällan felen innan koden exekverar (visst jslint och jshint finns men de är ganska odugliga, förutom att de dessutom klagar på helt valid kod).

Jag är inte lärare i programmering, men jag hade nog tusen fallt gånger hellre lärt ut python, ruby eller kanske än hellre smalltalk i första hand.

Jo, (att) jag nämnde dessa språk var för de alla är tolkade språk så som javascript och kräver absolut inget mer än miljö man kan ladda ner som är betydligt mindre än Chrome. 

Java är dessutom ett av de vanligaste språken inom industrin, sen kan man argumentera om språket som sådant (Jag är inget Java fan), men att kunna det är definitivt inte dåligt om man söker jobb som programmerare.

Men det beror samtidigt på vad man vill ha för jobb. Jag definierar som sagt själv inte webutvecklare som programmerare, är det vad man tänkt jobba med så är det kanske helt tokigt att gå på det direkt om man börjar från noll. 

Men som något generellt "lär dig programmera språk", håller jag som sagt med att det är iallafall i mina ögon en väldigt dålig ingångspunkt då man förr eller senare behöver "lära om" nästan allt.

Att göra en for loop, som exemplet var ser i princip identiskt ut oavsett språk (Och har de C dialekt så är det dessutom visuellt identiskt). 

class test {
 static public void main(Strings args[]) { 
    for(int x = 0; x < ... ; x++) {
System.out.println(x);
}
}
}

Känns för mig inte jobbigare att lära sig än 

for(var x = 0; x < ... ; x++) {
 console.debug(x);
}

Man sparar 4 rader som är en sak man skriver en gång för den klassen efter detta kan man modifera main-metoden hur mycket man vill utan att jag ser någon direkt förlust, att man sedan även per automatik kommer kunna lära ut koncept som stack, instans och klass variabler, olika scoop; public,private,protected osv, vilket blir ytterst svårt i javascript fallet då språket inte ens har stöd för hälften av detta.

Men det är kanske en smaksak... Vissa lärare verkar ju förespråka javascript.

LiU är ett bra alternativ om du vill ha jobb.

Du syftar tydligen på UN*X baserade system.

POSIX är inget ett system är baserat på utan en standard som uppfylls eller inte av ett system, POSIX står för Portable Operating System Interface (eXchange) och betyder enbart att systemet har ett API (Application Programmer Interface) som är baserat på någon av POSIX standarderna. 

De flesta system idag är mer eller mindre nära på 100% POSIX kompatibla, inklusive Windows. 

Att följa POSIX standarden är ett av kraven för att bli ett certifierad UNIX.

.NET fungerar förövrigt utmärkt på UN*X system, men man använder Mono istället för Microsofts CLR (Common Language Runtime). 

Än .NET? 

Assembler är inte "svårt" som många tycks få för sig, nackdelen är att assembler sällan är portabelt. Och det är ett ganska "verbose" språk så det kan vara svårt för någon extern part att sätta sig in i ett assembler program utan tydlig dokumentation. 

Med portabelt så menar jag inte enbart mellan olika typer av processorer utan mellan olika typer system också, 
Windows skickar tex inte argument på samma sätt som ex linux gör. Så om du vill släppa ditt program för ett annat system måste du spendera mycket tid på att modifiera stora delar för att få det att fungera. 

Det finns ingen med rätt prioriteringar som skriver program helt i assembler idag, däremot är det väldigt vanligt och kommer sannolikt förbli så för alla översiktlig framtid att man skriver om specifika funktioner i assembler för det kan ibland finnas stora mängder prestanda att hämta genom att göra det. 

Jag vill påpeka att det finns annat än "webb" och "backend" som man kan jobba med också.

Frontend och backend är termer för att beskriva systemarkitektur. 

Överlag så innebär det att en frontend är den del som visas mot användaren, backend är den del som hanterarbakom kulisserna ofta är termerna client och server synonymt.

Så backend är alltså generellt det som jobbar som du inte ser medans frontend generellt är gränsnittet utåt.

Ja, som sagt termerna kan tillämpas på olika delar av en produkt också vad som är en backend för något kan vara en frontend för något annat så det är väldigt abstrakta termer. 

Men jag gissar i sammanhanget så var innebörden om du vill syssla med design/hemsidosnickrande eller affärslogik på servern. 
Beroende på produkt så kan affärslogik vara hur stort som helst, vi har ca 5 komponenter på vår backend där det sitter totalt ca 400 personer och jobbar enbart på dessa delar, medans ca 80 jobbar med vår frontend.
Vissa jobbar med båda delar medan andra valt att fokusera på det ena eller det andra, vår klient har ganska mycket logik också (eftersom produkten ska hantera situationer utan en server backend också).

Nej det har de inte, det är en myt.

Jag jobbar med detta dagligen. Ja man förlorar i läsbarhet men läsbarhet betyder inte något i sammanhang där man kan vinna hundratusentals kr på att komma undan med mindre dyr hårdvara om samma algoritm går att optimera. 

En kompilator genererar generellt bättre kod än en nybörjare (Dvs någon som inte inser sammanhanget mer än vad instruktionerna gör) på assembler, men jämfört med någon som kan det så har den inte en chans och framförallt är problemet att kompilatorer omöjligt kan veta vad du vill utföra.

Sen i sammanhanget så om det inte är självklart så är förstås A och O att man väljer rätt algoritm till att börja med, men utan tvekan kan du minst höja prestanda på med 10% på i princip vilken algoritm som helst om du hand kodar den.

Det finns förutom (självklara) saker som att man lägger upp data på ett bra sätt i cachen, mängder med instruktioner på de flesta platformar som en kompilator under några omständigheter kommer generera. 

Optimeringstekniker för kompilatorer är lååååångt från optimala, men de gör ett acceptabelt jobb överlag men att skriva ett helt program i assembler tex är inget jag förespråkar med detta, optimering gör man på hotspots som man profilerar fram i de flesta fall. dvs kod som anropas ofta- detta är också något som en kompilator har svårt att förstå ibland då det inte alltid går att förutsäga vid kompileringstillfället hur koden kommer köras, JITar kan däremot göra detta så klart, men en JIT har istället andra nackdelar.

Detta är en ganska hyfsad post (Visserligen nästan 4 år gammal, men samma sak gäller fortfarande. Inget magiskt har hänt på kompileringsfronten de senaste 4 åren) som beskriver hur det är, även om han enbart optimerar genom att modifera C koden. http://lbrandy.com/blog/2010/06/you-cant-beat-a-good-compile/

Kundkontakt har säljare hand om. Deras språk är ungefär...

Kunden: Skulle ni kunna göra det här?
Säljare: Jajamän
Kunden: När har ni det klart då?
Säljare: i morgon

Det beror på hur du menar med effektivare, vi har en avdelning som jobbar med "Human Experience", dvs designa användargränsnittet så lätt användbart som möjligt. (Sen har jag ibland personliga åsikter om att de inte alltid har samma åsikt som mig i vad som är lättanvänt, för mig innebär lättanvänt något som liknar Apples produkter, få val; tydliga gränssnitt osv. Men det är en annan historia)

Men det låter som du är mer intresserad av design än utveckling i sig. Du bör tänka på att systemutveckling är mesta dels icke visuella saker. Att om en grafiker vill ha ett visst beteende är det din uppgift att försöka lösa detta på bästa möjliga sätt.

Själv har jag varit på nästan alla områden i den produkt vi har (utom just design då för det är inte min fallenhet även om jag kan göra vad jag tycker är acceptabel design, så har det väl sällan "pricken över i:t" när jag pillat på det.).

Sen är det ju självklart så att de flesta av oss kan förklara för en icke insatt person hur något fungerar men det är lättare att använda etablerade termer och förkortningar när man pratar med andra som sysslar med samma sak.

Jag rekommenderar i vilketfall, försök satsa på ett jobb som intresserar dig istället för att bry dig om lönenivåer osv.
Gör du ett bra jobb så kommer du få lön där efter och om man inte är intresserad så blir det sällan ett bra jobb utan man gör nog minsta möjliga för att lösa sin uppgift.

Kanske ska förtydliga, jag har varit nästan överallt inom utvecklingen på det företag jag jobbar på senaste 2 åren har jag inte jobbat med produktutveckling som sådan utan istället varit på forskning eller nu senast så knoppades vi av till en optimeringsgrupp som uteslutande jobbar med att optimera delar av produkten.

Men när jag jobbade med produktutveckling så hade jag aldrig kontakt med kunderna i sig, det närmsta man kom var om man fick flyga till någon kund och lösa problem eller undersöka saker på plats. Men då interagerar man med deras tekniker så det är sällan något problem att prata tekniskt då.

När jag var på forskning så var man ofta involverad i demo utveckling, dvs produkter som visades upp på mässor och inte allt för sällan var det snabba experimentella saker som ansågs "inne" vid tidpunkten och som man 99% av fallen skrev helt nytt, dvs icke tidstestad kod. Som resultat av detta fick man ofta följa med säljarna på mässor och ibland medans man var i "standby" ifall något skulle gå fel, så var man med och demonstrerade eller informerade om produkten. Problemet är väl snarast för min del att jag avskyr att ljuga för folk och det är tyvärr något som händer uteslutande i den här branchen. Det är aldrig ett företag som har en produkt klar som de säljer till någon, man presenterar tidsplaner som är helt orealistiska osv.
Så medans själva kommunikationen i sig inte är så svår så är det andra delar som är ganska obehagliga i sammanhanget.