Självlärd programmerare, är jag redo för att söka jobb? Detaljerad GitHub bifogad

Permalänk
Avstängd

Vilken succetråd det här blev för mig, nu ska jag sitta hela förmiddagen imorgon och gotta i mig grejer. Stort tack alla!

Permalänk
Skrivet av mwi:

Kollade genom din GitHub lite snabbt.
Jag skulle säga du ligger på samma nivå som en student efter ca 1-2 års studier.
Du behöver dock läsa på om testning och annat runt om kring grejor

Du kan definitivt söka jobb som junior utvecklare men du kommer inte få ett erbjudande på alla jobb som du söker.
Tyvärr är det framförallt utvecklare med lite erfarenhet som söks och din kod är inte på den nivån för att vara ärlig.
Men jag tror du kommer vara där relativt snabbt om du bara får lite riktig jobb erfarenhet.

Hej! Ursäkta om jag lånar tråden. Förhoppningsvis så kan ditt svar även vara vägledande för TS.

Jag som blivande Webbutvecklare är nyfiken på att få veta "hur man tar sitt kodande till nästa nivå"? Jag kommer själv att bli en student med 2 års studier efter avslutad distansutbildning.

Vad jag förstått så kommer designmönster, versionshantering, agile projektledning, och testning att läras ut under distansutbildningens gång, men det verkar vara mer "omkringliggande ämnen" än den faktiska kodningen?

En slutsats jag själv tog efter min första avslutade JavaScript-kurs var att det går att abstrahera koden mera. Exempelvis såg jag en person på webben som skrivit:

const clog = console.log;

Och utifrån detta så började jag fundera på hur man kunde abstrahera mer omfattande kod till mer kortfattad och samtidigt användbar kod. I mitt fall använde jag localStorage()-objektet en hel del.

Nu i efterhand efter avslutad första JavaScript-kurs så funderar jag på om det skulle ha gått att skriva en funktion som returnerar localStorage.setItem('key', value), eller localStorage.getItem('key', value) genom att bara ta tre argument: en för setItem eller getItem, en för key och en för value.

Med exemplet ovan så undrar jag helt enkelt om det är rätt tankesätt jag går nu med att abstrahera koden. Och om det överhuvudtaget är ett sätt att börja "ta sin kod till nästa nivå"? Eller måste man nästan kunna skapa en mindre fungerande AirBnB-sida för att visa vad man kan som webbutvecklare i dessa moderna tider?

Tack för ditt svar på förhand!

Mvh,
WKL.

Visa signatur

"Den säkraste koden är den som aldrig skrivs"

Permalänk
Medlem
Skrivet av first:

Tack, och jag ber om ursäkt för mitt förra något griniga svar. Det här var ett mycket bra svar.

Ett tips är att läsa text som att den är så välmenad som möjligt, framförallt om man själv är lite trött eller på dåligt humör, det minskar risken för tråkiga kommentarer som de ovan

Bättre att inte skriva något alls ibland, i alla fall bättre än att försöka bita tillbaka på något man kan ha tolkat fel. Mycket bra egenskap att kunna be om ursäkt också, så det uppskattas

Apier ska svara tydligt på felaktiga anrop eller data
Tester ska helst finnas på alla anrop, eller i alla fall flödestester på kedjor av anrop
Kommentarer i koden kan vara bra i komplicerade sammanhang eller dör det blev stökigt
Dokumentation av alla anrop i ett api är viktigt
Readme fil med projektets syfte och hur man sätter upp det (för att programmera och bygga från en ren dator, alla krav på mjukvaror och sånt)
Backlog för projektet, saker som kan förbättras, idéer som inte ännu gjorts, pågående ändringar, …
Någon form av mockad klient eller enklare testklient är bra att ha för att manuellt kunna testa och bygga ut ett API, kan absolut vara så enkelt som en HTML-sida med knappar och textfält

Finns mycket man kan göra, men man måste inte göra allt

Permalänk
Medlem
Skrivet av WebbkodsLärlingen:

Hej! Ursäkta om jag lånar tråden. Förhoppningsvis så kan ditt svar även vara vägledande för TS.

Jag som blivande Webbutvecklare är nyfiken på att få veta "hur man tar sitt kodande till nästa nivå"? Jag kommer själv att bli en student med 2 års studier efter avslutad distansutbildning.

Vad jag förstått så kommer designmönster, versionshantering, agile projektledning, och testning att läras ut under distansutbildningens gång, men det verkar vara mer "omkringliggande ämnen" än den faktiska kodningen?

En slutsats jag själv tog efter min första avslutade JavaScript-kurs var att det går att abstrahera koden mera. Exempelvis såg jag en person på webben som skrivit:

const clog = console.log;

Och utifrån detta så började jag fundera på hur man kunde abstrahera mer omfattande kod till mer kortfattad och samtidigt användbar kod. I mitt fall använde jag localStorage()-objektet en hel del.

Nu i efterhand efter avslutad första JavaScript-kurs så funderar jag på om det skulle ha gått att skriva en funktion som returnerar localStorage.setItem('key', value), eller localStorage.getItem('key', value) genom att bara ta tre argument: en för setItem eller getItem, en för key och en för value.

Med exemplet ovan så undrar jag helt enkelt om det är rätt tankesätt jag går nu med att abstrahera koden. Och om det överhuvudtaget är ett sätt att börja "ta sin kod till nästa nivå"? Eller måste man nästan kunna skapa en mindre fungerande AirBnB-sida för att visa vad man kan som webbutvecklare i dessa moderna tider?

Tack för ditt svar på förhand!

Mvh,
WKL.

Det är inte alls ’omkringliggande ämnen’ det är i allra högsta grad det sätt man jobbar med programmering på de allra flesta bolag. Inte all tid (kanske rent av hälften?) används till rem programmering och kodskrivande, resten är allt annat som att planera, sköta om tjänster, prata med kunder och användare, hålla koll på hur allt mår och sånt. Oftast är projekten långt större än att bara knacka kod

Permalänk
Avstängd
Skrivet av WebbkodsLärlingen:

Hej! Ursäkta om jag lånar tråden. Förhoppningsvis så kan ditt svar även vara vägledande för TS.

Jag som blivande Webbutvecklare är nyfiken på att få veta "hur man tar sitt kodande till nästa nivå"? Jag kommer själv att bli en student med 2 års studier efter avslutad distansutbildning.

Vad jag förstått så kommer designmönster, versionshantering, agile projektledning, och testning att läras ut under distansutbildningens gång, men det verkar vara mer "omkringliggande ämnen" än den faktiska kodningen?

En slutsats jag själv tog efter min första avslutade JavaScript-kurs var att det går att abstrahera koden mera. Exempelvis såg jag en person på webben som skrivit:

const clog = console.log;

Och utifrån detta så började jag fundera på hur man kunde abstrahera mer omfattande kod till mer kortfattad och samtidigt användbar kod. I mitt fall använde jag localStorage()-objektet en hel del.

Nu i efterhand efter avslutad första JavaScript-kurs så funderar jag på om det skulle ha gått att skriva en funktion som returnerar localStorage.setItem('key', value), eller localStorage.getItem('key', value) genom att bara ta tre argument: en för setItem eller getItem, en för key och en för value.

Med exemplet ovan så undrar jag helt enkelt om det är rätt tankesätt jag går nu med att abstrahera koden. Och om det överhuvudtaget är ett sätt att börja "ta sin kod till nästa nivå"? Eller måste man nästan kunna skapa en mindre fungerande AirBnB-sida för att visa vad man kan som webbutvecklare i dessa moderna tider?

Tack för ditt svar på förhand!

Mvh,
WKL.

En bra fråga, jag undrar också.
Rent syntaxmässigt så går det att lära sig ett par knep för att skriva så kort som möjligt, där har jag en del att hämta hem.
Det går även att koda för lägsta möjliga minnesallokering och med lägsta möjliga runtime. Jag känner till hur bägge beräknas men har massa kvar i att lära mig implementera de minst resurskrävande sätten, rent praktiskt.

Men när jag hör "ta koden till nästa nivå" så tänker jag på, ja jag vet inte riktigt för då hade jag redan försökt. Någon kombination av avancerade algos som kommer fram till något häftigt. Nästa nivå rent logikmässigt antar jag att man kan kalla det.

Vilket av dessa perspektiv är det man menar generellt om man pratar om "mer avancerad kod"? Eller är det något helt annat, som testing som det redan varits inne på? Eller en kombination av allt?

Permalänk
Avstängd

Går och lägger mig, snackas mer imorgon!

Permalänk
Medlem
Skrivet av first:

En bra fråga, jag undrar också.
Rent syntaxmässigt så går det att lära sig ett par knep för att skriva så kort som möjligt, där har jag en del att hämta hem.
Det går även att koda för lägsta möjliga minnesallokering och med lägsta möjliga runtime. Jag känner till hur bägge beräknas men har massa kvar i att lära mig implementera de minst resurskrävande sätten, rent praktiskt.

Men när jag hör "ta koden till nästa nivå" så tänker jag på, ja jag vet inte riktigt för då hade jag redan försökt. Någon kombination av avancerade algos som kommer fram till något häftigt. Nästa nivå rent logikmässigt antar jag att man kan kalla det.

Vilket av dessa perspektiv är det man menar generellt om man pratar om "mer avancerad kod"? Eller är det något helt annat, som testing som det redan varits inne på? Eller en kombination av allt?

I all fall vad jag sett är prestandaoptimering bara något man ger sig in på när man har tydliga problem, millisekunder är sällan något som påverkar slutresultatet (om man inte kodar realtid, alltså native c++ för spel eller något)

Samma gäller med att skriva kod snabbt, det är väldigt sällan relevant. Det som är relevant är att koden du skriver fungerar, är felhanterad och testad, lätt att förstå, …

Även om någon implementation kanske är dubbelt så snabb skulle jag oftast välja den som var lättast att förstå i de allra flesta fallen, någon annan kommer behöva öppna den filen om två år och antingen lägga till eller fixa något, då är det inte alls bra när det inte går att förstå enkelt vad som görs

Det går såklart att skriva kod som är båda snabb och går att förstå, men så länge man undviker de dummaste alternativen brukar mycket duga fint.

Dumma saker kan vara att parsea samma data många gånger, skicka allt som strängar som behöver läsas om många gånger, göra loopar i loopar, läsa samma data ur en databas många gånger vid samma anrop, … dessa går dock ofta enkelt att lösa om man tänker på vad man gör

Koden ska främst fungera, vara testad och gå att förstå, prestandan kommer oftast inte ens i tredje hand, och tiden den skrivs på är inte alls kritisk (alltså i måttet av rader/syntax per minut), utan måttet är hur lång tid man löser hela problemet på ett sätt som fungerar ihop med övrig kod utan att ställa till med andra problem och allt är testat och gör rätt

Permalänk
Medlem
Skrivet av WebbkodsLärlingen:

Hej! Ursäkta om jag lånar tråden. Förhoppningsvis så kan ditt svar även vara vägledande för TS.

Jag som blivande Webbutvecklare är nyfiken på att få veta "hur man tar sitt kodande till nästa nivå"? Jag kommer själv att bli en student med 2 års studier efter avslutad distansutbildning.

Vad jag förstått så kommer designmönster, versionshantering, agile projektledning, och testning att läras ut under distansutbildningens gång, men det verkar vara mer "omkringliggande ämnen" än den faktiska kodningen?

En slutsats jag själv tog efter min första avslutade JavaScript-kurs var att det går att abstrahera koden mera. Exempelvis såg jag en person på webben som skrivit:

const clog = console.log;

Och utifrån detta så började jag fundera på hur man kunde abstrahera mer omfattande kod till mer kortfattad och samtidigt användbar kod. I mitt fall använde jag localStorage()-objektet en hel del.

Nu i efterhand efter avslutad första JavaScript-kurs så funderar jag på om det skulle ha gått att skriva en funktion som returnerar localStorage.setItem('key', value), eller localStorage.getItem('key', value) genom att bara ta tre argument: en för setItem eller getItem, en för key och en för value.

Med exemplet ovan så undrar jag helt enkelt om det är rätt tankesätt jag går nu med att abstrahera koden. Och om det överhuvudtaget är ett sätt att börja "ta sin kod till nästa nivå"? Eller måste man nästan kunna skapa en mindre fungerande AirBnB-sida för att visa vad man kan som webbutvecklare i dessa moderna tider?

Tack för ditt svar på förhand!

Mvh,
WKL.

Nu är det ju ett enkelt exempel du tog men ofta är det bättre att funktioner/metoder/klasser har egna ansvar. Blir lättare att läsa, felsöka, bygga på etc. Finns risk att du sitter där med funktioner som behöver 8 argument för att göra sitt jobb.

Stötte på dylik kod under min LIA, seniorer som skrev ultradynamisk och krånglig/icke läsbar kod som inte ens de andra seniorerna förstod sig på.

Permalänk
Avstängd
Skrivet av first:

En bra fråga, jag undrar också.
Rent syntaxmässigt så går det att lära sig ett par knep för att skriva så kort som möjligt, där har jag en del att hämta hem.
Det går även att koda för lägsta möjliga minnesallokering och med lägsta möjliga runtime. Jag känner till hur bägge beräknas men har massa kvar i att lära mig implementera de minst resurskrävande sätten, rent praktiskt.

Men när jag hör "ta koden till nästa nivå" så tänker jag på, ja jag vet inte riktigt för då hade jag redan försökt. Någon kombination av avancerade algos som kommer fram till något häftigt. Nästa nivå rent logikmässigt antar jag att man kan kalla det.

Vilket av dessa perspektiv är det man menar generellt om man pratar om "mer avancerad kod"? Eller är det något helt annat, som testing som det redan varits inne på? Eller en kombination av allt?

Grundförståelse för kod är förstås viktigt, men andra saker är också viktiga. Att kunna tolka en kravspecifikation, att förstå tanken bakom en arkitektur, att kunna estimera någonstans i närheten av verkligheten, att kunna jobba med andra och så vidare. "Alla" kan lära sig att skriva kod (alla med en fallenhet för det i alla fall), men alla kan inte sätta prestigen eller egot åt sidan och jobba bra i ett team, ta till sig andra aspekter av ett problem och justera sina egna idéer efter dem och så. Att kunna förstå vad som är görbart och vad som inte är det även om det från ett högre perspektiv borde vara simpelt. Att vara grym på ett specifikt språk är inte så viktigt, syntaxen är inte det som tar tid att få in liksom.

Att skriva kortfattat är inte ett mål alls. Däremot att skriva förståeligt och strukturerat. Kommentarer där det behövs för att underlätta förståelsen av koden, men också där det behövs för att klargöra vad som är giltig input till en metod exempelvis.

Hade ni sökt jobb hos oss så hade följande saker varit positiva, förutom då rena programmeringskunskaper:
- Erfarenhet av micro services, med Kubernetes, Docker eller liknande bakom, och förstås hur man bygger smarta API:er i en sådan miljö, hur man hanterar redundans i en sådan miljö och så vidare.
- Erfarenhet av att bygga automatiserade acceptanstester med något ramverk eller någon allmän teknik, Specflow har vi använt en del exempelvis. Gärna i samband med micro services förstås.
- Bra på att bygga relevanta enhetstester, med dependency injection, mocking och så.
- Erfarenheter av agila utvecklingsmetoder. SCRUM, XP, SAFe eller liknande är bra.
- Erfarenheter av att skriva dokumentation på olika nivåer.
- "Personliga egenskaper". Detta betyder att man behöver visa sig hyfsat anpassningsbar och prestigelös.

Permalänk
Medlem
Skrivet av snajk:

Grundförståelse för kod är förstås viktigt, men andra saker är också viktiga. Att kunna tolka en kravspecifikation, att förstå tanken bakom en arkitektur, att kunna estimera någonstans i närheten av verkligheten, att kunna jobba med andra och så vidare. "Alla" kan lära sig att skriva kod (alla med en fallenhet för det i alla fall), men alla kan inte sätta prestigen eller egot åt sidan och jobba bra i ett team, ta till sig andra aspekter av ett problem och justera sina egna idéer efter dem och så. Att kunna förstå vad som är görbart och vad som inte är det även om det från ett högre perspektiv borde vara simpelt. Att vara grym på ett specifikt språk är inte så viktigt, syntaxen är inte det som tar tid att få in liksom.

Att skriva kortfattat är inte ett mål alls. Däremot att skriva förståeligt och strukturerat. Kommentarer där det behövs för att underlätta förståelsen av koden, men också där det behövs för att klargöra vad som är giltig input till en metod exempelvis.

Hade ni sökt jobb hos oss så hade följande saker varit positiva, förutom då rena programmeringskunskaper:
- Erfarenhet av micro services, med Kubernetes, Docker eller liknande bakom, och förstås hur man bygger smarta API:er i en sådan miljö, hur man hanterar redundans i en sådan miljö och så vidare.
- Erfarenhet av att bygga automatiserade acceptanstester med något ramverk eller någon allmän teknik, Specflow har vi använt en del exempelvis. Gärna i samband med micro services förstås.
- Bra på att bygga relevanta enhetstester, med dependency injection, mocking och så.
- Erfarenheter av agila utvecklingsmetoder. SCRUM, XP, SAFe eller liknande är bra.
- Erfarenheter av att skriva dokumentation på olika nivåer.
- "Personliga egenskaper". Detta betyder att man behöver visa sig hyfsat anpassningsbar och prestigelös.

Sista ordet där är verkligen a och o!

Man ska vara ödmjuk för vad andra kan och teamets vilja, även om man tycker att man har värsta bästa idén är det ofta man får acceptera att göra andra saker, och andra kommer ändra det man gjort av en hel hög anledningar. Det man alltid ska ha i siktet är det som är bäst för projektet. Så länge alla har det så blir det bra

Detta kan såklart leda till meningsskiljaktigheter, det är bara naturligt och bra för teamet och projektet, idéer förtjänar att ifrågasätta och förbättras av andra förslag. Ingen har en felfri tankeprocess

Permalänk
Medlem
Skrivet av ChrisDev:

Många hävdar väl att det är svårare att få jobb som självlärd utan någon utbildning på pappret. Sen säger väl inte det där pappret så mycket egentligen antar jag, men många verkar ändå ha det som krav. Enligt diverse poddar jag lyssnar på så har folk inte tid att kolla sökandes GitHub så noga. Verkar dessutom vara svårt även för vissa juniorer med utbildning att få jobb, många företag vill väl inte chansa antar jag.

Vilket tyvärr är väldigt märkligt då dom bästa utvecklare jag jobbat med i min karriär varit självlärda.

Permalänk
Avstängd
Skrivet av medbor:

Sista ordet där är verkligen a och o!

Man ska vara ödmjuk för vad andra kan och teamets vilja, även om man tycker att man har värsta bästa idén är det ofta man får acceptera att göra andra saker, och andra kommer ändra det man gjort av en hel hög anledningar. Det man alltid ska ha i siktet är det som är bäst för projektet. Så länge alla har det så blir det bra

Detta kan såklart leda till meningsskiljaktigheter, det är bara naturligt och bra för teamet och projektet, idéer förtjänar att ifrågasätta och förbättras av andra förslag. Ingen har en felfri tankeprocess

Ja precis. En relaterad sak som många har problem med, och som även jag tycker är svårt emellanåt, är ju att "chefen" (i begreppet inkluderar jag arkitekter, PO, projektledare och så vidare) bestämmer. Har du eller ditt team lagt ett år på att bygga en jättebra grej och chefen bestämmer att vi skiter i den, eller att den helt ska göras på ett annat sätt eller att något annat team ska ta över den, så är det så. För en konsult är det förstås ännu viktigare, men även en anställd kan ju inte gå runt och sura för att saker inte blev som tänkt liksom.

Permalänk
Medlem
Skrivet av WebbkodsLärlingen:

Jag som blivande Webbutvecklare är nyfiken på att få veta "hur man tar sitt kodande till nästa nivå"? Jag kommer själv att bli en student med 2 års studier efter avslutad distansutbildning.

Det kommer av sig självt, det gäller bara att ha drivet att hela tiden försöka bli bättre.

Skrivet av BasseBaba:

Vilket tyvärr är väldigt märkligt då dom bästa utvecklare jag jobbat med i min karriär varit självlärda.

Å andra sidan har 100% av alla cowboy-programmerare jag jobbat med varit självlärda.

Skrivet av snajk:

Ja precis. En relaterad sak som många har problem med, och som även jag tycker är svårt emellanåt, är ju att "chefen" (i begreppet inkluderar jag arkitekter, PO, projektledare och så vidare) bestämmer. Har du eller ditt team lagt ett år på att bygga en jättebra grej och chefen bestämmer att vi skiter i den, eller att den helt ska göras på ett annat sätt eller att något annat team ska ta över den, så är det så. För en konsult är det förstås ännu viktigare, men även en anställd kan ju inte gå runt och sura för att saker inte blev som tänkt liksom.

Det gäller att ha förståelse för vad som påverkar de val som görs. Ibland vill kunden inte lägga så mycket pengar på att fixa något på "rätt" sätt, och nyttan av en fulfix är så stor att man väljer att göra det så, då är det bara att göra det. Sitter man med en kodbas som man inte gillar är det bara att rätta sig efter den för det blir bara sämre om man gör saker på ett annat sätt. Och så vidare.

Nu för tiden så bryr jag mig inte i de val som görs, oavsett vad jag anser om dem. Men då brukar jag för det mesta också kunna komma med input på arkitektur, tekniska lösningar o.s.v. Det är litet annat när man är ny.

Visa signatur

Bra, snabbt, billigt; välj två.

Ljud
PC → ODAC/O2 → Sennheiser HD650/Ultrasone PRO 900/...
PC → S.M.S.L SA300 → Bowers & Wilkins 607

Permalänk
Avstängd
Skrivet av Phod:

Det kommer av sig självt, det gäller bara att ha drivet att hela tiden försöka bli bättre.

Å andra sidan har 100% av alla cowboy-programmerare jag jobbat med varit självlärda.

Det gäller att ha förståelse för vad som påverkar de val som görs. Ibland vill kunden inte lägga så mycket pengar på att fixa något på "rätt" sätt, och nyttan av en fulfix är så stor att man väljer att göra det så, då är det bara att göra det. Sitter man med en kodbas som man inte gillar är det bara att rätta sig efter den för det blir bara sämre om man gör saker på ett annat sätt. Och så vidare.

Nu för tiden så bryr jag mig inte i de val som görs, oavsett vad jag anser om dem. Men då brukar jag för det mesta också kunna komma med input på arkitektur, tekniska lösningar o.s.v. Det är litet annat när man är ny.

Jo, men det finns ju val på olika nivåer liksom. Jag har nu två gånger under senare år varit med om att ett projekt som jag och mitt team har hållit på med ganska länge, och som vi anser är en bra lösning, mycket bättre än vad vi hade innan (och har nu), ändå blir nedlagda på grund av att någon chef tappar tron på det. Inte att vi ska ändra lite, eller att vi har lagt en halv sprint på det, utan månader eller år för ett helt team med massor av resurser, många resor till kunder för att testa i andra länder och så, rätt i soporna. Jag vill inte bli bitter över det men som det kanske märks så är det svårt.

Permalänk
Medlem
Skrivet av snajk:

Jo, men det finns ju val på olika nivåer liksom. Jag har nu två gånger under senare år varit med om att ett projekt som jag och mitt team har hållit på med ganska länge, och som vi anser är en bra lösning, mycket bättre än vad vi hade innan (och har nu), ändå blir nedlagda på grund av att någon chef tappar tron på det. Inte att vi ska ändra lite, eller att vi har lagt en halv sprint på det, utan månader eller år för ett helt team med massor av resurser, många resor till kunder för att testa i andra länder och så, rätt i soporna. Jag vill inte bli bitter över det men som det kanske märks så är det svårt.

Men du har väl fått betalt? I sådana fall är det ju nästan bättre att det blir nedlagt, du får ingen ryggsäck att dras med! Sedan låter det här som taskigt ledarskap, och det är ju aldrig kul.

Visa signatur

Bra, snabbt, billigt; välj två.

Ljud
PC → ODAC/O2 → Sennheiser HD650/Ultrasone PRO 900/...
PC → S.M.S.L SA300 → Bowers & Wilkins 607

Permalänk
Avstängd
Skrivet av Phod:

Men du har väl fått betalt? I sådana fall är det ju nästan bättre att det blir nedlagt, du får ingen ryggsäck att dras med! Sedan låter det här som taskigt ledarskap, och det är ju aldrig kul.

Jo så är det förstås. Men mitt, och alla mina kollegors, liv hade varit mycket lättare om vi hade fått bli klara.

Permalänk
Medlem
Skrivet av snajk:

Jo, men det finns ju val på olika nivåer liksom. Jag har nu två gånger under senare år varit med om att ett projekt som jag och mitt team har hållit på med ganska länge, och som vi anser är en bra lösning, mycket bättre än vad vi hade innan (och har nu), ändå blir nedlagda på grund av att någon chef tappar tron på det. Inte att vi ska ändra lite, eller att vi har lagt en halv sprint på det, utan månader eller år för ett helt team med massor av resurser, många resor till kunder för att testa i andra länder och så, rätt i soporna. Jag vill inte bli bitter över det men som det kanske märks så är det svårt.

Hej!

Jag blir jättenyfiken på varför du tror att "chefen" tappar tron och bestämmer sig för att lägga ner projektet?

Funderingar,
- har ni släppt någon MVP som gör att det går att "uppleva" projektet på något sätt?
- handlar de tom förtroende att ni inte kan slutföra projektet eller att det varit för mycket omvägar på vägen?
- Bedöms det vara för mycket jobb kvar för att få ihop kalkylen på projektet?

/z

Visa signatur

C2D E6300 @ 3.2HGz 1.2V | Thermalright 120 Extr. | Gainward 8800 GT Golden Sample |Samsung 2x500Gb | Corsair VX 550V | Antec P182 [img]http://valid.x86-secret.com/cache/banner/421648.png[/img]

Permalänk
Medlem
Skrivet av zonar:

Hej!

Jag blir jättenyfiken på varför du tror att "chefen" tappar tron och bestämmer sig för att lägga ner projektet?

Funderingar,
- har ni släppt någon MVP som gör att det går att "uppleva" projektet på något sätt?
- handlar de tom förtroende att ni inte kan slutföra projektet eller att det varit för mycket omvägar på vägen?
- Bedöms det vara för mycket jobb kvar för att få ihop kalkylen på projektet?

/z

Kan handla om så enkla saker som att ett sälj misslyckades och ett projekt stannar, eller att det bedöms konkurrera med ett annat team eller blir för stor omskrivning att det blir mer kod att underhålla

Vi har extremt många sådana ’halvklara’ poc-projekt som ligger som beta-releaser eller är i produkten men inte används av någon utom för demo

En specifik produkt vi lade ett helt år på blev aldrig stabil nog och ingen kunde lösa det (så ingen kund ville ha det)

Sånt händer ibland

Gäller främst att ha bra relationer mellan chefer och utvecklare. Vår PO är mer av en i teamet och litar fullt på oss, andra team jobbar på helt andra sätt

Permalänk
Avstängd

Om det dyker in någon ny i tråden nu, så är länken till min GitHub numera död då jag bytt användarnamn. Har flyttat alla wiki-pages till respektive readme.md också och putsat lite i formateringen.

Min plan nu är att börja söka lite jobb, och medans jag väntar på svar om intervju så ska jag:
Läsa på om testing samt implementera det i åtminstone ett av mina projekt, antagligen 'Online Surgeon'.
Läsa om agile, lean, scrum, kanban, devops
Försöka hitta ett open-source projj på GitHub inom en sektor jag kan tänka mig att jobba inom, och se om jag kan bidra med något.

Återigen ett stort tack för all respons.

Permalänk
Medlem
Skrivet av first:

Om det dyker in någon ny i tråden nu, så är länken till min GitHub numera död då jag bytt användarnamn. Har flyttat alla wiki-pages till respektive readme.md också och putsat lite i formateringen.

Min plan nu är att börja söka lite jobb, och medans jag väntar på svar om intervju så ska jag:
Läsa på om testing samt implementera det i åtminstone ett av mina projekt, antagligen 'Online Surgeon'.
Läsa om agile, lean, scrum, kanban, devops
Försöka hitta ett open-source projj på GitHub inom en sektor jag kan tänka mig att jobba inom, och se om jag kan bidra med något.

Återigen ett stort tack för all respons.

Fördelen med opensource är att man kan se att du kan:
1. Jobba i större projekt
2. Skriva kod som passar in
3. Skriva kod som följer befintliga strukturer
4. Skriva kod som accepteras av befintliga
5. Förstå en existerande kodbas
6. Göra ändringar som inte förstör befintligt

Om du lyckas med att få in en pull-request i ett större projekt är det nästan en given intervjuanledning

Permalänk
Avstängd
Skrivet av zonar:

Hej!

Jag blir jättenyfiken på varför du tror att "chefen" tappar tron och bestämmer sig för att lägga ner projektet?

Funderingar,
- har ni släppt någon MVP som gör att det går att "uppleva" projektet på något sätt?
- handlar de tom förtroende att ni inte kan slutföra projektet eller att det varit för mycket omvägar på vägen?
- Bedöms det vara för mycket jobb kvar för att få ihop kalkylen på projektet?

/z

Jag kan ju förklara lite om det största projektet. Vi bygger en mjukvara som styr hårdvara, som mitt företag också bygger (i ett annat bolag visserligen). Så vi har hela stacken från PLC:er och liknande på själva hårdvaran via en lösning med micro services och en webb-frontend upp till att integrera mot kundernas system långt upp. Förutom en liten bit mellan hårdvaran och systemet liksom. Den köper vi in från ett annat företag och den är inte bara dyr, jobbig att använda och byggd på uråldrig teknik utan också väldigt begränsande i vad vi kan göra med vår hårdvara och mjukvara. Dessutom tvingar denna mjukvara (eller snarare villkoren antar jag) oss att köpa dyr teknik från företaget som bygger den istället för på "öppna marknaden" eller direkt från tillverkarna, som säkerhetssensorer, positioneringssensorer, diverse "datorer" som sitter på hårdvaran och så. Ett stort problem med denna lösningen är att varje situation måste liksom vara specificerad hur den ska lösas i förväg. Vem ska "gå först" i denna "korsning"? Det måste man tänka kring och specificera specifikt, sen samma för alla andra hundratals liknande situationer. Vårt projekt hade löst detta dynamiskt istället utan att någon behövde tänka på varenda ställe, vilket hade minskat tiden för en installation från veckor till dagar.

Projektet jag jobbade med syftade till att ersätta en stor del av denna mjukvara och på sikt helt bli av med den. Anledningen till att vi inte satsade på att helt ersätta den från början var att den var säkerhetsklassad på ett sätt som var ganska komplicerat och vi ville fixa funktionaliteten främst så att vårt system fungerade mer "modernt", mer reaktivt, tog hänsyn till mer än en sak när den fattade beslut, möjlighet att ändra beslut eller instruktioner som redan skickats och så. Att helt få bort den hade sparat pengar och underlättat på många sätt, men rent funktionellt så hade vår första lösning hjälpt väldigt.

Detta projekt påbörjades innan jag var anställd där och jag blev anställd specifikt för att jobba med det. Vi tog också in en del konsulter som var experter på detta område som hamnade som utvecklare i mitt team och så. I ungefär ett år från att jag blev anställd, så jobbade vi på med bara mjukvara, vi hade en egen simulator för tredjepartsdelarna vi behövde behålla, men körde också med den faktiska mjukvaran i ett simulerat läge. Sen testade vi i vårt lab, vilket gjorde att vi insåg att verkligheten var mer komplicerad än en simulerad verklighet, trots att labbet är ganska simpelt jämfört med en kundinstallation. Så vi körde en del i labbet, löste problem som hittades och så, sen fick vi tag i en testkund. Detta var en ganska liten installation. Om labbet var 1X så var detta kanske 4X i storlek och komplexitet. Igen hittade vi saker som vi inte hade sett innan och löste dem allteftersom de poppade upp. Sen kom det ett säljcase med ett megaprojekt som hade varit omöjligt att lösa med den befintliga lösningen, men som passade oss som hand i handske. Den befintliga lösningen kunde hantera kanske 15-20X i komplexitet men här var det mer 60X, med extrema krav på prestanda och throughput. Kunden var väldigt tveksam till att vi skulle lösa det då de hade "köpt" en lösning från en leverantör som hade tre år på sig men som inte lyckats på den tiden, och som de nu hade stämt för kontraktsbrott. Men jag sålde in vår lösning, att den närmade sig release och att den kunde hantera komplexiteten och prestandakraven, så det blev så.

Vi var inte färdiga med den första "pilotkunden" men vi hade löst de problem de hade som gjorde dem villiga att låta oss testa där, så vi släppte det och hoppade på megaprojektet istället. Så vi satsade hårt på det, körde tester mot deras flöden och så, och emellanåt spenderade vi väldigt mycket tid hos denna kund (i ett annat land) och testade på hårdvara i den faktiska miljön men innan anläggningen var klar. Kundens projektledare, eller inte slutkunden utan den som var ansvarig för helhetslösningen mot slutkund (vår del var "bara" några hundra miljoner i ett mångmiljardprojekt), var extremt petig och nitisk dock.

Vi fick aldrig köra systemet mer än några minuter innan han skulle in och peta, ställa till problem, täcka för sensorer, sparka på grejerna och så. Så vi fick skifta fokus från "prestanda" till "stabilitet" trots att det var väldigt osannolika saker som de "testade". Vi la kanske ett halvår på att bygga om hela vår huvud-algoritm så att den, så fort något problem uppstod, liksom kastade ut allt och räknade om hela lösningen på situationen. Vi fick allt att funka, systemet var superstabilt, man kunde blockera uppemot hälften av maskinerna och de övriga snurrade ändå på (trots att allt påverkar allt annat), men prestandan hade ju dippat en aning av denna effort och således nådde vi bara 90% av deras förväntade peak. Den peaken låg dock flera år bort så vi var ju helt säkra på att vi hade löst det långt innan dess.

Men. Samtidigt som detta pågick så hade mitt företag, utan att vara öppna med det, satt ett annat team på att bygga en helt annan lösning specifikt för denna kund. Den byggde på ännu äldre teknik och det teamet var tvungna att översätta kod från tjugo är gamla saker och språk och så. Och den var ju verkligen byggd bara för detta projektet, med hårdkodade saker överallt och så. Sen fick de någon att köra prestandatester, bakom vår rygg, och han kom fram till att vår lösning var aningen långsammare i dagsläget. Vart beslutet sen fattades vet jag inte, men nedläggningen kom inom kort i alla fall.

Permalänk
Medlem
Skrivet av first:

Om det dyker in någon ny i tråden nu, så är länken till min GitHub numera död då jag bytt användarnamn. Har flyttat alla wiki-pages till respektive readme.md också och putsat lite i formateringen.

Min plan nu är att börja söka lite jobb, och medans jag väntar på svar om intervju så ska jag:
Läsa på om testing samt implementera det i åtminstone ett av mina projekt, antagligen 'Online Surgeon'.
Läsa om agile, lean, scrum, kanban, devops
Försöka hitta ett open-source projj på GitHub inom en sektor jag kan tänka mig att jobba inom, och se om jag kan bidra med något.

Återigen ett stort tack för all respons.

Länka den nya

Om jag förstod det rätt så skrev du Online Surgeon i Java, använd JUnit för att testa, enkelt att komma igång med.

unit-tests är otroligt viktigt för att se till så att dina metoder fortfarande gör vad du förväntar att de gör när du refaktoriserar eller lägger till ny kod.

Visa signatur

CPU: Ryzen 5600xGPU: 1080 TI ROG Strix RAM:2x16GB G.skill Trident @ 3600MHz MoBo: Asus B550FPSU: Corsair SF750
En resa till Nordkorea
2 dagar i Tjernobyl

Permalänk
Avstängd
Skrivet av Pelegrino:

Länka den nya

Om jag förstod det rätt så skrev du Online Surgeon i Java, använd JUnit för att testa, enkelt att komma igång med.

unit-tests är otroligt viktigt för att se till så att dina metoder fortfarande gör vad du förväntar att de gör när du refaktoriserar eller lägger till ny kod.

Ja precis. Enhetstester är inte (främst) för att testa att saker funkar nu, utan att de inte går sönder i framtiden när någon är inne och ändrar i koden, eller andra breaking changes från externt håll.

Permalänk
Avstängd
Skrivet av Pelegrino:

Länka den nya

Om jag förstod det rätt så skrev du Online Surgeon i Java, använd JUnit för att testa, enkelt att komma igång med.

unit-tests är otroligt viktigt för att se till så att dina metoder fortfarande gör vad du förväntar att de gör när du refaktoriserar eller lägger till ny kod.

https://github.com/alex-strae
Pirrigt att lägga ut något med bild på sig, haha.
Super Deliveries API och HoMM är de projekt jag vart mest hängiven i. Dom är pinnade på första-sidan nu.

Ska definitivt kolla upp grunderna inom testing.

Permalänk
Medlem
Skrivet av medbor:

Även om någon implementation kanske är dubbelt så snabb skulle jag oftast välja den som var lättast att förstå i de allra flesta fallen, någon annan kommer behöva öppna den filen om två år och antingen lägga till eller fixa något, då är det inte alls bra när det inte går att förstå enkelt vad som görs

Det går såklart att skriva kod som är båda snabb och går att förstå, men så länge man undviker de dummaste alternativen brukar mycket duga fint.

Dumma saker kan vara att parsea samma data många gånger, skicka allt som strängar som behöver läsas om många gånger, göra loopar i loopar, läsa samma data ur en databas många gånger vid samma anrop, … dessa går dock ofta enkelt att lösa om man tänker på vad man gör

Koden ska främst fungera, vara testad och gå att förstå, prestandan kommer oftast inte ens i tredje hand, och tiden den skrivs på är inte alls kritisk (alltså i måttet av rader/syntax per minut), utan måttet är hur lång tid man löser hela problemet på ett sätt som fungerar ihop med övrig kod utan att ställa till med andra problem och allt är testat och gör rätt

En reflektion från utveckling av inbyggda system (alltså "backend på riktigt" ): Hos oss är prestanda i exekvering väldigt avgörande! Detta gör att det är ännu viktigare att kunna abstrahera koden (och i brist på det kommentera ordentligt) på ett bra sätt, så att kompilatorn kan producera optimal maskinkod. Det gäller också att man har koll på hur kompilatorn hanterar saker i vissa fall.

Resten är dock rakt av applicerbart och bra sammanfattat.

Permalänk
Avstängd
Skrivet av Penguin:

En reflektion från utveckling av inbyggda system (alltså "backend på riktigt" ): Hos oss är prestanda i exekvering väldigt avgörande! Detta gör att det är ännu viktigare att kunna abstrahera koden (och i brist på det kommentera ordentligt) på ett bra sätt, så att kompilatorn kan producera optimal maskinkod. Det gäller också att man har koll på hur kompilatorn hanterar saker i vissa fall.

Resten är dock rakt av applicerbart och bra sammanfattat.

Blev fångad här, vad innebär inbyggda system? Är det system där man förväntar sig liten, om någon alls, interaktion från människa genom gränssnitt? Egentligen bara system för att hålla en maskin igång och tillåta den att utföra det den är byggd för att utföra? Exempelvis en bil eller t. om kylskåp?

Kanske hävde ur mig en kavalkad av felaktiga antaganden nu men blev lite upphetsad, haha.

Permalänk
Medlem
Skrivet av WebbkodsLärlingen:

Hej! Ursäkta om jag lånar tråden. Förhoppningsvis så kan ditt svar även vara vägledande för TS.

Jag som blivande Webbutvecklare är nyfiken på att få veta "hur man tar sitt kodande till nästa nivå"? Jag kommer själv att bli en student med 2 års studier efter avslutad distansutbildning.

Vad jag förstått så kommer designmönster, versionshantering, agile projektledning, och testning att läras ut under distansutbildningens gång, men det verkar vara mer "omkringliggande ämnen" än den faktiska kodningen?

En slutsats jag själv tog efter min första avslutade JavaScript-kurs var att det går att abstrahera koden mera. Exempelvis såg jag en person på webben som skrivit:

const clog = console.log;

Och utifrån detta så började jag fundera på hur man kunde abstrahera mer omfattande kod till mer kortfattad och samtidigt användbar kod. I mitt fall använde jag localStorage()-objektet en hel del.

Nu i efterhand efter avslutad första JavaScript-kurs så funderar jag på om det skulle ha gått att skriva en funktion som returnerar localStorage.setItem('key', value), eller localStorage.getItem('key', value) genom att bara ta tre argument: en för setItem eller getItem, en för key och en för value.

Med exemplet ovan så undrar jag helt enkelt om det är rätt tankesätt jag går nu med att abstrahera koden. Och om det överhuvudtaget är ett sätt att börja "ta sin kod till nästa nivå"? Eller måste man nästan kunna skapa en mindre fungerande AirBnB-sida för att visa vad man kan som webbutvecklare i dessa moderna tider?

Tack för ditt svar på förhand!

Mvh,
WKL.

När jag tittar på TS's kod så ser jag enkla projekt som har blivit lösta med enkel kod.
Nu ska man naturligtvis lösa enkla problem på enkla sätt men det säger mig samtidigt att TS inte har erfarenhet med mer komplexa problem.
Jag kan naturligtvis ha fel då jag faktiskt inte vet vad TS kan då jag har bara hans GitHub att gå på.

Så jag uttryckte mig lite dåligt men jag hade gärna sett någon mer komplext projekt.
Tex att ha delaktig i ett Open source project
Andra saker jag skulle vilja se är unit tester och interaktion mellan olika tjänster.
Tex skulle hans "Online Surgeon" ha kunnat finnas som ett API på AWS som snackar med ett fristående GUI och samtidigt vara kopplat till tex google kalender eller liknande.
Detta tillsammans med någonting som "aws cdk" där han har lagt in sin infrastruktur som kod och kanske kopplat github actions för automatisk deployar vid commit hade sagt mig att han legat på en mycket högre nivå. (Blev en massa buzzwords där )

Till frågan "hur man tar sitt kodande till nästa nivå" så är det med erfarenhet. Ju mer man kodar ju mer lär man sig och så länge man tar till vara på dom erfarenheterna som kommer man (nästan) automatiskt dit
Men även att förstår alla dom där "runt om kring" grejorna är en viktig del när man kommer ut i arbetslivet. Det kanske inte känns som det är direkt kopplat till hur man kodar men det finns så mycket hjälpmedel nuförtiden så för att kunna koda bra och effektivt så behöver man förstå verktygen lika mycket som själva koden.

Och ja, jag vet att detta var ett väldigt filosofiskt svar men av min erfarenhet (20 år) så är det inte en eller några specifika grejor som jag kan peka på, utan det viktigaste enligt mig är att få erfarenhet och att att ta tillvara på den erfarenheten.
Sen kan man alltid specialisera sig mot något speciellt område men själva grunden bygger på erfarenhet.

Permalänk
Medlem
Skrivet av first:

Blev fångad här, vad innebär inbyggda system? Är det system där man förväntar sig liten, om någon alls, interaktion från människa genom gränssnitt? Egentligen bara system för att hålla en maskin igång och tillåta den att utföra det den är byggd för att utföra? Exempelvis en bil eller t. om kylskåp?

Kanske hävde ur mig en kavalkad av felaktiga antaganden nu men blev lite upphetsad, haha.

Embedded, alltså smarta saker med mikrocontrollers och sånt, där minnesmängden liknar datorer från 70/80-talen och ingen prestanda alls att tala om (och kanske ska köara sig åratal på ett litet knappcellsbatteri)

Där är det väldigt viktigt med prestanda och olika optimeringar så inget äter resurser och energi i onödan

Permalänk
Medlem
Skrivet av first:

Blev fångad här, vad innebär inbyggda system? Är det system där man förväntar sig liten, om någon alls, interaktion från människa genom gränssnitt? Egentligen bara system för att hålla en maskin igång och tillåta den att utföra det den är byggd för att utföra? Exempelvis en bil eller t. om kylskåp?

Kanske hävde ur mig en kavalkad av felaktiga antaganden nu men blev lite upphetsad, haha.

Skrivet av medbor:

Embedded, alltså smarta saker med mikrocontrollers och sånt, där minnesmängden liknar datorer från 70/80-talen och ingen prestanda alls att tala om (och kanske ska köara sig åratal på ett litet knappcellsbatteri)

Där är det väldigt viktigt med prestanda och olika optimeringar så inget äter resurser och energi i onödan

Inbyggda system varierar från, som @medbor är inne på, en liten smart pryl men också datorsystemen som styr nätverk (telekom, internet etc.), bilar, flygplan osv. Väldigt många inbyggda system behöver uppgraderingar och ny funktionalitet kontinuerligt under hårdvarans livlängd, på samma sätt som andra mjukvarusystem.
Att påstå att det inte finns någon prestanda i inbyggda system skulle jag säga är helt felaktigt, men man har däremot en fördefinierad mängd beräkningskraft,minne och andra egenskaper från när systemet designats, och du behöver ta hänsyn till det på ett annat sätt än i en vanlig applikation.

Permalänk
Avstängd
Skrivet av medbor:

Embedded, alltså smarta saker med mikrocontrollers och sånt, där minnesmängden liknar datorer från 70/80-talen och ingen prestanda alls att tala om (och kanske ska köara sig åratal på ett litet knappcellsbatteri)

Där är det väldigt viktigt med prestanda och olika optimeringar så inget äter resurser och energi i onödan

Ok! Är det jag beskrev någon sektor? Hur ser marknaden ut för Embedded, är det något man kan ta sig in på som självlärd? Är det C som gäller då?