Lära mig programmera

Python används i min erfarenhet mest av folk som inte är programmerare som behöver visa ett koncept eller bygga någon liten grej som underlättar deras arbete på något sätt. Typ BA, projektledare och liknande.

Inte enligt min erfarenhet.

På mitt jobb byggs det en del grejer i Python, men inte av utvecklarna som sagt.

Har jobbat med PHP sedan ~2001/2003.
Redan för 12 år sedan hörde jag talas om alla nya heta kandidater som skulle slå ut PHP.

Nu har jag jobbat 20 år med bland annat PHP och har väll 20 år kvar inom utveckling skulle jag tror. Jag kör vidare, har sett många ramverk och språk komma o gå men PHP det består!

Låter fint att jobba på ett ställe där huvudfokus är att saker fungerar och inte att man har den nyaste coola tekniken... suck.

Det verkar vara ganska ovanligt ja. Vet att min kollega som var CTO på annat bolag bytte ut PHP stacken för GO för att kunna attrahera nya utvecklare. La säkert 2 år på rewrite och rekrytering.
Jag är inte personen som kan avgöra om det var rätt, men han uppnådde målet med att kunna rekrytera många Duktiga och unga utvecklare och produkten blev väldigt bra i slutändan. Men det tog som sagt 2 år att bygga samma system i Go för att sedan ta det vidare.

Jag är själv egentligen inte så märkvärdigt duktig utvecklare i just PHP trots att jag kodat i det i 20 år. Däremot så har jag "gjort alla misstag" redan så jag kör väll på rent jävlaranamma och slutför och sparar tid genom att jag har just erfarenheten och vet vilken lösning av dom Jag kan som passar bäst, finns säkert många bättre lösningar men finessen är att veta vad som löser uppgiften på ett acceptabelt, tryggt och snabbt sätt.

Ja det är väl inte fel att använda en ny teknik i en del situationer. Problem blir det däremot när man byter tekniken om och om igen innan folk ens har hunnit bekanta sig med den. Ofta har samma företag/organisationer samma tendenser när det gäller exempelvis arbetsmetodik och så.

Ett litet men ändå störande exempel är att mitt företag har kört på Story Points som motsvarar en snittperson en dag ungefär i estimeringar och så (tidigare hade vi att en halv poäng var ungefär en dag för en person), nu har de ändrat så att en story point ska motsvara ett helt team i en hel sprint. I och med det blir story points helt värdelösa för oss utvecklare då vi som sagt använder de i våra estimeringar och nu kan vi alltså inte ta in mer än en poäng i en sprint. Skalan sätts av verktygen vilket innebär att det minsta man kan sätta på en feature är en halv poäng och allt som tar mer än en sprint måste förstås delas upp i mindre bitar. Så nu är våra val en halv poäng eller en poäng. De tänker väl att det ska underlätta för ledning och liknande att ha mindre siffror att bolla med, men samtidigt går det ju inte att jämföra längre då. Vi har ett antal utvecklingsteam med varierande kompetens och antal personer så poängen blir då teamspecifika. Sen är det ju ingen som översätter tidigare features och stories så de kommer att se väldigt stora ut.

Är lite på samma resa, har sökt en YH utbilding som VR utvecklare. Förhoppningsvis kommer man in nu till hösten. Själv velar jag mellan unity och unreal. Dock sneglar jag lite på godot också, eftersom det är en sådan trevlig motor att leka i. Dock är ju Unity och Unreal industristandard. Hur tycker du om att jobba med VR i unreal?

Jag vill joina Har också precis bestämt mig för det och researchat massor. Jag tänkte dock börja med Java Script, kanske CSS och HTML också men det kan ju vara bra ändå! Bolla idéer och allt sådant!
Ha det fint!

Länk till discord gruppen?

https://discord.gg/zbF3USCV

ehhh varför heter den något polskt

Tja, ett team som känner varandra skulle jag säga kan estimera, eller i alla fall bedöma effort, hyfsat även för lite större grejer. Under förutsättning att de är tillräckligt specificerade förstås.

Exempelvis kanske mitt team har byggt en (micro-) service för att göra en specifik sak tidigare. Nu ska vi bygga en ny service för att göra något annat liknande. Vi kanske behöver lite mer logik på ett ställe och bedömer att det ökar på estimatet med 20%, men kanske slipper en viss typ av detaljerad loggning då denna servicen inte är lika kritisk, så minus 10% där. Men i allmänhet, att bygga en service enligt våra generella krav, med API, DB, scaffolding, loggning, enhetstest och liknande är ju ändå ganska samma liksom. Sen får man förstås öka på alla estimat baserat på osäkerhet. Om något inte är specificerat tillräckligt noga så kommer det nästan oundvikligt att komma upp fler saker som vi inte har haft med i beräkningen, alltså lägger vi på poäng/tid ganska kraftigt i sådana fall. Behöver något testas på fysisk hårdvara i labbmiljö då simulerat inte fångar alla edge-cases så vet vi att det tar minst tre dagar extra exempelvis. Är man beroende av andra team, att de ska bygga färdigt något för att vi ska kunna slutföra så ökar det på också förstås, väntetiden behöver man ju inte ta med men i allmänhet blir det en massa tid lagd på att förklara, diskutera och hjälpa till (alltså internsupport).

Samtidigt har du absolut rätt i att större grejer är omöjliga att räkna på med någon exakthet. Men då brukar vi ta i helt enkelt. Och det gäller ju att planera sprintar med mycket luft, speciellt om man kan räkna med att behöva fixa buggar (eller change requests på grund av dålig specifikation) på tidigare byggd funktionalitet. Ska vi använda någon ny teknik som ingen i teamet har erfarenhet av så brukar vi ungefär dubbla estimatet jämfört med om vi hade byggt det med något vi kunde, men det varierar ju lite. Det är inte ett jättesteg att gå från MS SQL till någon annan SQL-variant exempelvis, lite mer komplext till säg MongoDB, men om ett team ska gå från exempelvis MVC till att plötsligt bygga GUI i Angular så är det bra mycket mer än en dubbling i tid första gången.