Wellbok - well...

[Slaktavfall]

Varför går guld upp i pris ifall den inte används i industrin?

 

Ungefär 1/5 av allt nyproducerat (gruvdriftsframtaget) guld går direkt in i industriella tillämpningar. Det är lite magstarkt att påstå att dessa ~500 ton inte används i industrin

 

För bara några år sedan vara denna siffra 10%.

 

I takt med att priset på guld stiger tvingas man ofta använda andra alternativ (med sämre materialegenskaper), t.ex. iridium, palladium, platina och silver. Även om man med ett högre pris skulle lyckas pressa ned den industriella tillämpningen till 10-15% igen skulle användningen i absoluta tal fortsätta öka på sikt.

 

Ny teknik, främst lågtemperaturbaserad nanoteknik, kommer förmodligen skapa än större industriell efterfrågan på guld.

 

Det finns 180 000 ton guld i världen och det produceras ungefär ~2500 ton per år. Nyproduktion + omsättning av gammalt guld motsvarar efterfrågan + omsättningstryck.

 

Nyproduktion utgör alltså 1-2% av den totala tillgången.

 

Det betyder att en plötslig dump av stora befintliga guldreserver skulle destabilisera priset markant. Om centralbanker fick för sig att sälja stora delar av sina reserver skulle vi onekligen få ett prisfall.

 

Men guld kommer aldrig bli "värdelöst" eftersom det har så åtråvärda materialegenskaper. Priset kan t.ex. aldrig någonsin gå extremt långt under de sämre alternativen iridium, palladium eller platina.

[Trillske]

Angående IT-marknaden ska man även ha klart för sig att de flesta inte skriver "high quality code". Detta inkluderar konsulter som tar en väldig massa betalt. Det ska gå snabbt och (förhoppningsvis) fungera. Röra.

 

Finessen med programmering är imo att koden å ena sidan ska vara robust (ska inte finnas någon chans att du anropar "luft", alla tänkbara fel ska fångas upp osv) å andra sidan simpel och vem som helst ska fatta hur du har tänkt. Har du tänkt fel eller något inte går som det är ska är du alltså fel att kliva runt det på något icke intuitivt sätt knappt du själv vet varför det funkar, men så har du en beställare som kräver snabba resultat så du leverar röran och hoppas det inte krånglar (för då går det inte att debuga, framförallt inte för kunden).

 

Jag tycker rent av visual basic (utan ide) är roligt nu helt plötsligt. Det är lite simpelt men det gör också att man på något vis hamnar så "nära" koden. Man måste designa allt själv och får ta eget ansvar för att det blir en rimlig struktur.

 

Gick en kurs i Java på lith, strukturer och algoritmer, som var grymt bra. Jag har gått massvis med programmering men detta är den enda som sitter kvar; hör nördarnas tjat om dittan och dattan i bakhuvudet hela tiden.

[heltok]

I fall detta scenario utspelar sig.Vad ska man investera i då? Dollar?

Det är ju en rätt komplex fråga, men generellt kan väl säga att allt annat blir dyrare. Om det stiger i värde vetefan.

 

Tror det hela blir klarare om du ser vad som hände med Zimbabwebörsen:

Vi kan nog säga att om man misstänkte att zimbabwedollar var en dålig investering så hade det varit en bra ide att t ex sälja sina zimbabwedollar och köpa aktier.

 

Imo så man bör resonera om man inte tror på fiat-valuta. Sälja det och köpa annat, t ex aktier, bitcoin, hus eller konst. Något man tror har högre värde i framtiden.

 

Ska vi köpa bitcoin för allt vi äger? Det känns rätt riskabelt.

Imo sätt lite procentsatser i ditt huvud. Sedan sätter du utilityvärde av olika typer av förmögenhet. Sedan optimerar du hyfsat.

 

Tror du att det är 1/100 att bitcoin stiger 10000x kanske en lämplig summa att investera i BTC är 1/10 av det du äger. Tror du siffran är 1/1000 kanske 1/100 är lämpligt. Lite beroende på din utilityfunktion.

 

En uppdelning där vi har en stor del av vår förmögenhet i guld, liten del i fiat (för dagliga transaktioner innan bitcoin funkar fullt ut) och resten i bitcoin känns väll rätt rimligt?

Jag ser inget direkt värde i att ha guld i min egen portfölj.

 

Varför går guld upp i pris ifall den inte används i industrin?

Vill påpeka att guld har tappat ca 10000x i pris senaste 4åren:

http://pricedingold.com/charts/BTC-2010.pdf

 

Antar att du syftat på priset i dollar. Antagligen för att mängden pengar ökar och för att många indier, kineser m fl inte har så många andra alternativ för sina sparpengar.

 

Det innebär också bugfri, fungerande och läsbar kod. Att lära sig det kräver en kombination av att programmera mycket och vara nyfiken på att hela tiden lära sig mer. Så finns nog tyvärr inga quick fixes där.

Men borde väl finnas någon föreläsningsserie som igår igenom lite exempel på bra och dålig kod?

 

Hittade denna:

Men den går mest igenom vad man ska kalla varibler och indentering etc. Jag vill ha snygga matematiska lösningar, rätt ordning i while-loopar, hur man sorterar en matris etc.

 

Priset kan t.ex. aldrig någonsin gå under silver eller platina.

Framtiden är oviss imo, vill inte säga aldrig om sånt här. Vem vet, vi kanske börjar handla med någon annan planet med massa guld och lite silver som fullständigt älskar solpaneler?

[Slaktavfall]

Framtiden är oviss imo, vill inte säga aldrig om sånt här. Vem vet, vi kanske börjar handla med någon annan planet med massa guld och lite silver som fullständigt älskar solpaneler?

 

Med tanke på de energimängder som åtgår vid just intergalaktisk handel med tunga saker, typ metaller, verkar det osannolikt att man skulle kunna få upp solpanelernas verkningsgrad så till den grad, att man på något sätt skulle lyckas räkna hem den dealen. Om man nu inte vill ha solpanelerna endast som prydnad.

[Katt3n]

IT-marknaden är ganska bra nu.

 

Snarare: ITmarknaden är bra för vissa nischer i storstadsområdena.

 

Rekryterar folk till en ort två timmar från storstad just nu. 120 sökande till en nybörjartjänst.

[fjohansson]

Snarare: ITmarknaden är bra för vissa nischer i storstadsområdena.

 

Rekryterar folk till en ort två timmar från storstad just nu. 120 sökande till en nybörjartjänst.

 

haha what!? programmeringstjänst? vi sitter ~45 min från gbg och har problem med att hitta folk. 2-3 sökande per tjänst vare sig det gäller frontend eller backend (ehandel- magentoplattform). å andra sidan så är det väl förmodligen för nära gbg.

[Trillske]

Borde också vara lite skillnad om det står "intresserad av programmering" eller "krav på relevant höskoleexamen och relevant erfarenhet" i annonsen?

[Katt3n]

haha what!? programmeringstjänst? vi sitter ~45 min från gbg och har problem med att hitta folk. 2-3 sökande per tjänst vare sig det gäller frontend eller backend (ehandel- magentoplattform). å andra sidan så är det väl förmodligen för nära gbg.

 

Nejfan inget så exotiskt. Vanlig hederlig supporttjänst. Allt från lycksökande hädttjejer och plattläggare till folk med 20 års senior erfarenhet från diverse stora firmor som skär ner (logica, volvo it osv)

[Batch]

Snarare: ITmarknaden är bra för vissa nischer i storstadsområdena.

 

Rekryterar folk till en ort två timmar från storstad just nu. 120 sökande till en nybörjartjänst.

Låter som om ni skjuter väldigt brett i eran annons?

 

Nu jobbar jag i Stockholm och det är säkert som du skriver att det skiljer sig markant från mindre orter men här känns det som om det skriks efter personer med programmeringskunskaper.

 

Jag jobbar som utvecklare på ett företag som utvecklar och tillhandahåller betallösningar för e-handel och vi skulle anställa fler om vi fick tag på kompetenta utvecklare. Kraven är dock rätt högt ställda då "trial and error" inte lämpar sig när man jobbar med bank- och korttransaktioner.

 

På mitt förra jobb på ett större IT-konsultbolag dammsög man bokstavligt talat universitet och högskolor efter personer att anställa. Man tog i stort sett in vem som helst kändes det som ibland. Medförde självklart en mängd felanställningar som kostade pengar...

 

Om man är en utvecklare med några år i branschen blir man sönderspammad av rekryterare på LinkedIn.

 

 

heltok: Läs Code Complete om du vill bli en bättre programmerare.

[fjohansson]

http://diablo3story.blogspot.se/2014/07/a-diablo-3-story.html

 

TLDR: I made about 100 000 euro from Diablo 3 in exactly 1 year. Below I will tell you in great detail how.

[heltok]

http://diablo3story.blogspot.se/2014/07/a-diablo-3-story.html

 

Läste hela, väl värd en läsning. Hoppas liknande kommer om poker framöver

[ViktorH]

Läste hela, väl värd en läsning. Hoppas liknande kommer om poker framöver

 

sååå läst. lät nice

[Trillske]

Har inte tänkt på det men den där typen av bot-användning är ju standard (och relativt simpel) automatisering, det jag har varit inne på bara en bråkdel av mänskligheten (inklusive företagsvärlden) förstått sig på ännu. Det där automatiserings-konceptet är inte det minsta olikt det jag gör på mitt jobb egentligen, vilket i princip är egensnickrad situation (bara jag visste ens från början att det behövdes/var lönsamt).

 

För semi-nördiga människor i vår generation tror jag problemet är att man sällan fattar precis hur simpla och extremt lönsamma grejer som inte genomförts ännu, antingen för att folk inte vet om möjligheten eller för att den där kompetensen inte varit på plats, simpel eller ej.

[Luskan]

Har inte tänkt på det men den där typen av bot-användning är ju standard (och relativt simpel) automatisering, det jag har varit inne på bara en bråkdel av mänskligheten (inklusive företagsvärlden) förstått sig på ännu. Det där automatiserings-konceptet är inte det minsta olikt det jag gör på mitt jobb egentligen, vilket i princip är egensnickrad situation (bara jag visste ens från början att det behövdes/var lönsamt).

 

För semi-nördiga människor i vår generation tror jag problemet är att man sällan fattar precis hur simpla och extremt lönsamma grejer som inte genomförts ännu, antingen för att folk inte vet om möjligheten eller för att den där kompetensen inte varit på plats, simpel eller ej.

 

Pratar du om enklare scripts/program som förenklar arbetsrutinerna eller syftar på mer "big picture" rationaliseringar?

[Trillske]

Pratar du om enklare scripts/program som förenklar arbetsrutinerna eller syftar på mer "big picture" rationaliseringar?

Båda! Enkla scripts kan göras på en timme för en massa excel/outlook grejer som folk gör dagligen. Inte bara enkelt och snabbt dessutom gör inte folk fel (databas istället för att folk plockar fel adresser osv).

 

Sen är det klart att det varierar beroende på företag, men mitt intryck än så länge är att det är standard att göra omständliga, komplexa och manuella saker på industriföretag (vilket såklart är ironiskt).

 

Big picture blir ju mer komplicerat på många sätt, inte minst för att man vid någon nivå alltid är bunden till affärssystemet så dyra lösningar kan bli redundanta vid stora förändringar osv. Det vore kul att vara med att utveckla sådant i framtiden dock. Idag bygger jag bara enklare skal kring affärssystemet och även där får man ju avgöra vad som är värt tiden vs hur stor risk det är att saker förändras.

[Luskan]

Båda! Enkla scripts kan göras på en timme för en massa excel/outlook grejer som folk gör dagligen. Inte bara enkelt och snabbt dessutom gör inte folk fel (databas istället för att folk plockar fel adresser osv).

 

Sen är det klart att det varierar beroende på företag, men mitt intryck än så länge är att det är standard att göra omständliga, komplexa och manuella saker på industriföretag (vilket såklart är ironiskt).

 

Big picture blir ju mer komplicerat på många sätt, inte minst för att man vid någon nivå alltid är bunden till affärssystemet så dyra lösningar kan bli redundanta vid stora förändringar osv. Det vore kul att vara med att utveckla sådant i framtiden dock. Idag bygger jag bara enklare skal kring affärssystemet och även där får man ju avgöra vad som är värt tiden vs hur stor risk det är att saker förändras.

 

På mitt jobb (som produktutvecklare inom bilindustrin) så arbetas det ganska kontinuerligt med s.k. förbättringsarbete där vi utvecklar arbetsrutinerna. Det har dock inte alltid varit så vilket märks ibland. Vissa saker fattar man inte varför folk inte automatiserat och andra fall blir man paff över vad som kan ske automatiskt.

 

Nackdelen med att ha hemmasnickrade skripts i sina rutiner är att kunskapen om hur det fungerar ofta stannar hos personen som gjort skriptet. När personen sen slutar eller byter position så försvinner kompetensen och det blir väldigt svårt (dyrt) att uppdatera skriptet.

 

Fördelen är dock uppenbar; genom egna skräddarsydda skripts till den egna utvecklingsprocessen så skapar man sig en edge mot andra som sitter och gör saker som man alltid gjort.

 

Har själv precis fått uppdraget att göra en större uppgradering på just ett så'nt script där skaparen försvunnit.

[nizzestrom]

Jag må vara ung, och framförallt naiv, men det är väl "bara" skriva tydliga noteringar i koden?

[Trillske]

På mitt jobb (som produktutvecklare inom bilindustrin) så arbetas det ganska kontinuerligt med s.k. förbättringsarbete där vi utvecklar arbetsrutinerna. Det har dock inte alltid varit så vilket märks ibland. Vissa saker fattar man inte varför folk inte automatiserat och andra fall blir man paff över vad som kan ske automatiskt.

 

Nackdelen med att ha hemmasnickrade skripts i sina rutiner är att kunskapen om hur det fungerar ofta stannar hos personen som gjort skriptet. När personen sen slutar eller byter position så försvinner kompetensen och det blir väldigt svårt (dyrt) att uppdatera skriptet.

 

Fördelen är dock uppenbar; genom egna skräddarsydda skripts till den egna utvecklingsprocessen så skapar man sig en edge mot andra som sitter och gör saker som man alltid gjort.

 

Har själv precis fått uppdraget att göra en större uppgradering på just ett så'nt script där skaparen försvunnit.

Känner igen detta och har hittills löst det på två sätt:

1) Outsourcing. Jag tog ett stort och dåligt fungerande moment och styckade ned stora delar av det vilka sedan kunde kodas ERP-oberoende till att bli rent intuitiva processer, som sedan bara lämnar kvar och rapporterar problem där det faktiskt behövs speciella åtgärder av någon kompetent. Sedan outsourcas grovjobbet vilket innebär att man slipper administrativa djungler på kontoret och per konstruktion räknar med att byta personal för de uppgifterna.

 

Jag har då haft fördelen av "koncern-interna" möjligheter till outsourcing vilket förenklar detta (jobbigt att lämna ut företagsdata etc).

 

2) Jag bygger ett VB-makro som kommer fria 4-5 timmar om dagen (för kompetent och viktig personal) samt standardisera vissa utföranden och där blir upplägget helt enkelt att konstruera en enkel manual samt kortare utbildning av en mer pålitligt fast anställd. Eftersom makro är på formen "gå dit, gör detta" går det att lära sig göra ändringar i detta bara man kan affärssystemet, även utan kodvana.

 

Nackdelen med makro-upplägget är ju annars att det kan räcka med en sketen liten uppdatering för att sabba programmet.

 

----------------

 

Visst är det ett ständigt problem men jag undrar om inte många är lite "egoistiska" med sin kompetens också, så att det blir ännu större problem än det borde. Jag arbetar tvärt om och försöker mer eller mindre övertala folk att fatta vad jag pysslar med. Jag har till och med varit på min chef om att han måste sätta igång och rekrytera och utbilda någon som ersätter delarna som gör mig vital (på kort varsel) på kontoret.

 

Detta är såklart inte alltruism utan tvärt om vad jag ser som en rimlig metod att bli eftertraktad.

 

Mina 2 cent så att säga.

 

Jag må vara ung, och framförallt naiv, men det är väl "bara" skriva tydliga noteringar i koden?

Om det är enkelt och välskrivet program är ju detta inget problem för någon med grundläggande kod-förståelse.

 

Har personen dock tex noll erfarenhet av att koda kommer den inte se skillnad på en kommentar och en for-loop. Det känns märkligt om man föds in det men är antagligen ganska självklart.

[heltok]

Har försökt studera lite kod. En sak som slår mig är att bra kod verkar vara väldigt simpel. Mycket handlar om att skriva underfunktioner och variabler i klasser etc och väldigt sällan blir det särskilt krångliga uttryck. Min egen kod blir indentering efter indentering, medan t ex denna koden är massa klasser och funktioner med bara en indentering eller max två:

https://github.com/bitcoin/bitcoin/blob/d17ce77fc178f16cfe63e9de6f5bcc445fabe1cb/src/main.cpp

 

Även lite krångligare funktioner är väldigt platta:

https://github.com/bitcoin/bitcoin/blob/d17ce77fc178f16cfe63e9de6f5bcc445fabe1cb/src/crypto/sha2.cpp

 

Antar min egen programmeringsstil är ungefär:

1. Snabbt som fan lösa problemet slarvigt

2. Rätta till felen

3. Strukturera om koden

4. Gör om från början, se vad som behövs och inte behövs

 

Är detta en bra strategi? Känns som man ofta fastnar runt 2 och knappt fattar vad man sysslar med. Har ni någon bättre strategi?

 

---

 

Fin text:

http://www.mises.se/2014/08/12/fiende-nummer-ett/

 

---

 

Rätt skön serie:

 

FP-ledaren Jan Björklund citerade Olof Palme i sitt sommartal - en pik mot de rödgrönas brist på regeringsbesked och gemensamt valmanifest. Vad är det för fel på den gemensamma borgerliga politiken eftersom ni aldrig låter väljarna ta ställning till den i ett fritt demokratiskt val? undrade Palme.

 

Men Löfven kontrar:

 

"Om Alliansen så skriver tio valmanifest, så samlar de i dag 36—38 procent. Då blir frågan: med vem ska de göra upp?"

[Rampart]

Har försökt studera lite kod. En sak som slår mig är att bra kod verkar vara väldigt simpel. Mycket handlar om att skriva underfunktioner och variabler i klasser etc och väldigt sällan blir det särskilt krångliga uttryck. Min egen kod blir indentering efter indentering, medan t ex denna koden är massa klasser och funktioner med bara en indentering eller max två:

https://github.com/bitcoin/bitcoin/blob/d17ce77fc178f16cfe63e9de6f5bcc445fabe1cb/src/main.cpp

 

Även lite krångligare funktioner är väldigt platta:

https://github.com/bitcoin/bitcoin/blob/d17ce77fc178f16cfe63e9de6f5bcc445fabe1cb/src/crypto/sha2.cpp

 

Antar min egen programmeringsstil är ungefär:

1. Snabbt som fan lösa problemet slarvigt

2. Rätta till felen

3. Strukturera om koden

4. Gör om från början, se vad som behövs och inte behövs

 

Är detta en bra strategi? Känns som man ofta fastnar runt 2 och knappt fattar vad man sysslar med. Har ni någon bättre strategi?

 

 

Jag jobbar som systemutvecklare hos ett större IT-bolag och tycker det hela är väldigt beroende av uppdrag/syfte.

 

Vi jobbar mer efter principen "good enough" än gto-lösningar. Det innebär inte att man skriver slarvig och ful kod, men mer att du inte behöver kasta massor tid på att optimera mot perfektion, bara för att det går och kan tyckas vara sexigt.

 

Det kanske behövs om du jobbar med system där millisekunder gör skillnad. Men annars (för majoriteten av utvecklingsjobben, skulle jag säga) är det skitsamma.

 

Skriv tydlig kod, håll det så enkelt som möjligt. För läsbarhetens skull kan man mycket hellre skriva 2-3 rader kod istället för att trycka ihop anrop i en oläsbar-lång-och-nästlad-följd. Ingen rocket science direkt men mina 2 cents som jag själv har klarat mig bra på. Sedan är jag inte direkt någon stjärnkodare, google hade inte direkt anställt mig...

 

Sist men inte minns: precis som med ALLT så tar coding-skills tid. Koda mycket, pröva och lek mycket. De som slaktar stack overflow drömmer ju kod liksom...

[devalanteriel]

I tillägg till ovanstående: testa att som programmeringsövning göra precis tvärtom en gång. Skriv koden som du vill att den ska se ut, och skriv sedan funktionerna du anropar efteråt. Jobba dig nedåt i kedjan tills du är klar. Det är inte säkert att du är så du vill jobba sen, men det är kul att testa och en nyttig erfarenhet. Also, har du aldrig kodat funktionellt så gör det också, så du får testa på skillnaden.

[Batch]

Det kanske behövs om du jobbar med system där millisekunder gör skillnad. Men annars (för majoriteten av utvecklingsjobben, skulle jag säga) är det skitsamma.

Framför allt är det nästan alltid billigare att köpa extra datorkraft än vad optimeringarna kostar i utvecklingstid.

[Luskan]

Jag må vara ung, och framförallt naiv, men det är väl "bara" skriva tydliga noteringar i koden?

 

Är koden längre än 100 rader så räcker det inte med bra kommentarer imo, det måste finnas en vettig struktur också. Det är ju inga programmerare som skriver koden utan oftast maskiningenjörer (eller dylikt). På min utbildning (maskinteknik @ LTU) ingick det ingen utbildning i hur man skriver bra kod.

Efter att ha läst en tillvald grundkurs i c på universitetet samt en helt del kodande på fritiden så anser jag mig vara långt ifrån en expert men ändå ha ganska bra koll på hur man ska skriva program. Trots detta så tänker jag nästan efter varje program jag skriver; 'oj...hade jag gjort om programmet från början så hade jag börjat i en helt annan ände eller gjort på ett helt annat sätt'. Man lär sig eftersom I guess.

 

 

Känner igen detta och har hittills löst det på två sätt:

1) Outsourcing. Jag tog ett stort och dåligt fungerande moment och styckade ned stora delar av det vilka sedan kunde kodas ERP-oberoende till att bli rent intuitiva processer, som sedan bara lämnar kvar och rapporterar problem där det faktiskt behövs speciella åtgärder av någon kompetent. Sedan outsourcas grovjobbet vilket innebär att man slipper administrativa djungler på kontoret och per konstruktion räknar med att byta personal för de uppgifterna.

 

Jag har då haft fördelen av "koncern-interna" möjligheter till outsourcing vilket förenklar detta (jobbigt att lämna ut företagsdata etc).

 

Vi provade faktiskt att outsourca en uppgift i vintras vilket gick sådär. Uppgiften var att anpassa en mjukvara (skriva ett skript/makro till mjukvaran) som förbearbetar våra beräkningsmodeller till våra krav och våran arbetsmiljö. Outsourcningen gjordes till företaget som utvecklar mjukvaran i fråga vilket kan verka klockrent. Men tvärtemot så tog det väldigt lång tid innan denne person (kön lämnar jag åt fördomar och fantasin) att förstå vad vi egentligen ville ha. Det hade sannolikt gått fortare om någon redan insatt på våran avdelning gjorde arbetet.

 

2) Jag bygger ett VB-makro som kommer fria 4-5 timmar om dagen (för kompetent och viktig personal) samt standardisera vissa utföranden och där blir upplägget helt enkelt att konstruera en enkel manual samt kortare utbildning av en mer pålitligt fast anställd. Eftersom makro är på formen "gå dit, gör detta" går det att lära sig göra ändringar i detta bara man kan affärssystemet, även utan kodvana.

 

Nackdelen med makro-upplägget är ju annars att det kan räcka med en sketen liten uppdatering för att sabba programmet.

 

En annan nackdel kan vara att man gömmer moment som är viktiga att förstå. Det blir lätt 'tryck på knappen och få reda på om balken håller'.

 

--

 

 

Två rumregler som brukar göra koden hyfsat läsbar:

 

*En funktion ska rymmas på skärmen

*Skriv in rader längre än 80 tecken

[nizzestrom]

Är koden längre än 100 rader så räcker det inte med bra kommentarer imo, det måste finnas en vettig struktur också. Det är ju inga programmerare som skriver koden utan oftast maskiningenjörer (eller dylikt). På min utbildning (maskinteknik @ LTU) ingick det ingen utbildning i hur man skriver bra kod.

 

I see. När du säger det så. Har samarbetat med en civilingenjör, som inte läst programmering separat, i några matematikkurser och jag känner igen det du pratar om från hans kodande i matlab. Inte på något sätt obegåvad vad gäller det logiska men det var ett jävla virr-varr när han satte igång och skrev.

 

Spagghettikod som min fantastiska programmeringslärare uttryckte det.

[Trillske]

Vi provade faktiskt att outsourca en uppgift i vintras vilket gick sådär. Uppgiften var att anpassa en mjukvara (skriva ett skript/makro till mjukvaran) som förbearbetar våra beräkningsmodeller till våra krav och våran arbetsmiljö. Outsourcningen gjordes till företaget som utvecklar mjukvaran i fråga vilket kan verka klockrent. Men tvärtemot så tog det väldigt lång tid innan denne person (kön lämnar jag åt fördomar och fantasin) att förstå vad vi egentligen ville ha. Det hade sannolikt gått fortare om någon redan insatt på våran avdelning gjorde arbetet.[/Quote]I det här fallet är det dock inte kodandet som är outsourcat; jag kodar saker för att kunna outsourca momenten (de är på tok komplexa ursprungligen). Det blir såklart en del kompromissande, inte minst agerar programmet utifrån genererade rapporter och rör varken affärssystem eller centrala databaser, d.v.s. det blir en rejäl inbyggd flaskhals vad gäller informationsflödet. Så då får man istället designa utefter vissa tidsintervall och lägga upp rutiner för att X görs på förmiddagen och Y görs på eftermiddagen osv.

 

Grunden till den här idén kom av att jag tyckte vi arbetade helt bedrövligt bakvänt med vissa fundamentala grejer, och när jag började utreda det där var folk väldigt positiva så jag fick mer och mer tid för det. Så fick jag fram rimlig data att börja arbeta ifrån, gjorde processbeskrivningar, kodade verktyg och insåg rätt snabbt att... jaha, sen då? Ska jag sitta här och trycka på knappar 30 min om dagen? Det är liksom inte min typ av jobb. Resultatet är oundvikligt: jag gör jobbet i en månad, lessnar, går vidare och försvinner och så gör även mina program och rutiner.

 

Så istället är allt byggt med tanken redan från början att vara ett outsourcat moment med mycket låga krav på IT-kompetens, väldigt kort utbildningsbehov, etc. Så får man skala processerna utifrån det.

En annan nackdel kan vara att man gömmer moment som är viktiga att förstå. Det blir lätt 'tryck på knappen och få reda på om balken håller'.

Ja detta är också något man får jobba på. Vi har många (för många) som sitter onödigt djupt och knappar direkt in i affärssystemet där jag jobbar, men det blir ju en övervägning också; att för många måste kunna för mycket är antagligen åtminstone mindre dåligt än raka motsatsen. Jag arbetar både med att bygga skal för att dölja komplexitet samtidigt som jag lär ut en hel del om hur affärssystemet agerar. Det blir såklart lite motsägelsefullt men min avvägning än så länge är att man känner av om det är en person som vill (eller mer eller mindre måste för att ens stanna) utvecklas eller en person som helst av allt vill gå till jobbet, göra något som sitter i ryggmärgen, och komma hem utan att vara trött.

 

Sistnämnda finns det alltid en hel del av och det finns ingen som helst logik i att pressa in en massa lågnivå-förståelse där, det gör bara att utbildningstiden för positionen blir längre och inte minst att momenten utförs långsammare och med mycket mer frekventa fel. Bättre då att de får vara den typen av administratörer jag själv är direkt olämplig som (om jag har understimulerade arbetsuppgifter börjar jag göra annat om dagarna, kommer sent på morgnarna till jobbet, jobbar väldigt disträ etc.. det är inte ett dugg snyggt men jag känner till det iaf så jag vet hur jag undviker situationen).

 

Antar min egen programmeringsstil är ungefär:

1. Snabbt som fan lösa problemet slarvigt

2. Rätta till felen

3. Strukturera om koden

4. Gör om från början, se vad som behövs och inte behövs

Antagligen kommer det rätt fort av att du börjar göra riktiga saker du har användning för. Jag tycker det är svårt att bli duktig när man bara programmerar "skräp", min utvecklingskurva är enormt mycket brantare nu när jag utvecklar saker som har rejäl användning. Jag kodar tex alltid objektorienterat även i VBA nu och det blir imo en annan grej på så vis att om man ska bygga något med bara några hundra rader kod och gör det i VBA så är det inte direkt det intuitiva att göra det objektorienterat. Det är alltså plötsligt ett helt eget initiativ för att göra koden begripligare, lättare att kontrollera, bygga vidare på osv, tvärt emot att sitta i Java och lära sig att "designa program såhär eller gtfo" typ. Plötsligt är teknikerna lösningar faktiska problem jag har och då blir det lättare att lära sig. Åtminstone för mig är tex debug i skolbänken ett tråkigt moment som måste göras för att läraren blir grinig annars, medan jag nu känner enorm belöning av att hitta smarta sätt att göra koden debug-vänlig. Det är nämligen inge kul att leverera program man inte har kontroll på.

 

Just ovanstående punktlista är precis beteendet jag kom ifrån genom att alltid programmera OO. Då måste man ofta bara komma på vilken/vilka klasser man behöver snarare än att hela visionen för programmet ska vara komplett på förhand.

 

Att döma av vad jag sett i tokboken kanske du får problemet att du bygger för långa funktionsanrop och "matematisk-funktion-i-matematisk-funktion" och liknande (typ: "jamen vadå klart detta blir rätt igen om man bara drar % på uttrycket och dividerar med 4.2 här och 3.52 där borta"), du verkar ha en intuitiv förståelse för saker de flesta tycker är rörigt och opedagogiskt.

 

Jag programmerade med en sådan kille på universitetet. Brutalt smart vad gäller logik-matte, riktigt, riktigt skarp. Vände och vred på funktioner i huvudet och pang, så lägger han till något för mig helt obegripligt till uttrycket och så funkar det. För honom var det naturligt.

 

Men grejen är att koden i slutändan blev ju bedrövlig. Så om man inte lär sig använda den kompetensen på rätt sätt är det ju snarare en svaghet.