A Anders_Nilsson skrev:
Det är inte Microsoft PowerBI vi talar om?

Sedan är min uppfattning att är man över 40 är man rökt. För 20 år sedan var jag en jävel på C/C++ och det räckte för ett välbetalt jobb. Idag är C/C++ grundplåten i vad en utcvecklare kan, sedan är det ett antal scriptspråk och dessutom diverse system som JIRA/DevOps för ärendehantering som gäller.

Jag har lyckligtvis rört mig vidare så jag hoppa kunna behålla jobbet till 65 alternativ få ett paket vid dryga 60 men jag inser att jag är en australopitechus inom mjukvaruutveckling.
VA? Ålder har väl inte något med det att göra... Intresse däremot!

Jag är rätt nära 50 och började programmera Node.js och VTL för ca. 5 år sedan på heltid.
Innan dess var det mest C++ och Java och jag inledde min programmeringskarriär i mitten av 90-talet med Visual Basic 5 och sen Delphi.
 
  • Älska
guggen
  • Laddar…
MrJay
Låter som Python är klockrent utgångsläge för TS med tanke på tänkt ändamål. Annars kan du börja som jag med x86 Assembly och arbeta dig bakåt/uppåt (beroende på hur man ser det) som jag :cool:
 
A Anders_Nilsson skrev:
Det är inte Microsoft PowerBI vi talar om?

Sedan är min uppfattning att är man över 40 är man rökt. För 20 år sedan var jag en jävel på C/C++ och det räckte för ett välbetalt jobb. Idag är C/C++ grundplåten i vad en utcvecklare kan, sedan är det ett antal scriptspråk och dessutom diverse system som JIRA/DevOps för ärendehantering som gäller.

Jag har lyckligtvis rört mig vidare så jag hoppa kunna behålla jobbet till 65 alternativ få ett paket vid dryga 60 men jag inser att jag är en australopitechus inom mjukvaruutveckling.
Jobben inom IT o utveckling fasas ut för Sveriges del till förmån för låglöneländer ex Indien Spanien, Tjeckien mfl länder. Jobbat själv inom IT i 20år som sql specialist. Min son framgångsrik fullstack programmerare men redan som 30 åring insett att man måste redan byta bana till administratör
 
anders07 anders07 skrev:
Helt rätt, men problemet idag är att objektorienterad programmering (OOP) och "skripting" (procedurell programmering, PP) börjar gå isär väldigt mycket.

OOP som t.ex. Java och C# är en helt annan typ av programmering än t.ex. Node.js (PP).
I dagsläget får man nog välja spår och i mitt tycke är PP en säkrare framtid...

C# i Functions/micro-services som @AndersMalmgren nämnde är väl egentligen något mellanting mellan OOP och PP.
Det är ju fortfarande c# vilket i grunden är OOP. Men de flesta seniora utvecklare kodar mer funktionellt eller producurellt. Även inom OOP så frångår man mycket av de klassiska problemen tex använder man komposition istället för arv (Composition over inheritance). Själv kör jag ganska funktionellt även i C#

Exempel från min domän på jobbet
Kod:
public class RefundStrategy : IAmountDeviationStrategy
{
   public AmountDeviationStrategy Strategy => AmountDeviationStrategy.Refund;

   public PaymentInvoiceMatchResult Execute(MatchJob job)
   {
       if (job.Diff < 0)
           return new PaymentInvoiceMatchResultBuilder(job)
               .PaymentCategory(PaymentCategory.WrongPayment)
               .RefundAll(RefundReason.UnderPaid);

       var invoiceAmount = Math.Abs(job.Invoice.Amount);
       var payingPayments = GetPaymentsComboClosestToInvoiceAmount(job.Payments, invoiceAmount);

       var refunds = job.Payments.Except(payingPayments).ToList();
       var result = new PaymentInvoiceMatchResultBuilder(job, refunds)
           .PaymentCategory(PaymentCategory.WrongPayment)
           .Refund(refunds);

       if (payingPayments.Sum(p => p.Amount) != invoiceAmount)
           result.Refund<RefundSplitPaymentCommand>(payingPayments.First(p => p.Amount >= job.Diff), split => split.Amount = payingPayments.Sum(p => p.Amount) - invoiceAmount);

       return result
           .QueueCommand(new MapInvoicePaymentsCommand { InvoiceId = job.Invoice.ExternalId, Payments = payingPayments.Select(p => p.ExternalId) });
   }

   private IReadOnlyCollection<IPaymentMatchInfo> GetPaymentsComboClosestToInvoiceAmount(IReadOnlyCollection<IPaymentMatchInfo> payments, decimal invoiceAmount)
   {
       var combos = Enumerable.Range(1, payments.Count)
           .SelectMany(i => new Combinations<IPaymentMatchInfo>(payments, new ReferenceCompare<IPaymentMatchInfo>(), i))
           .ToList();

       var payingPayments = combos
           .Where(c => c.Sum(p => p.Amount) >= invoiceAmount)
           .OrderBy(combo => Math.Abs(combo.Sum(p => p.Amount) - invoiceAmount))
           .First();

       return payingPayments;
   }
 
H håbbe1961 skrev:
Jobben inom IT o utveckling fasas ut för Sveriges del till förmån för låglöneländer ex Indien Spanien, Tjeckien mfl länder. Jobbat själv inom IT i 20år som sql specialist. Min son framgångsrik fullstack programmerare men redan som 30 åring insett att man måste redan byta bana till administratör
Då söker man åtminstone inte jobb i Stockholm... Här är det huggsexa om alla programmerare!
Enda orsaken till att vi outsourcar är att vi inte får tag på rutinerade utvecklare...

De få vi faktiskt lyckas få intervjua har oftast redan ett antal andra erbjudanden...
 
  • Gilla
AndersMalmgren och 1 till
  • Laddar…
AndersMalmgren AndersMalmgren skrev:
Det är ju fortfarande c# vilket i grunden är OOP. Men de flesta seniora utvecklare kodar mer funktionellt eller producurellt. Även inom OOP så frångår man mycket av de klassiska problemen tex använder man komposition istället för arv (Composition over inheritance). Själv kör jag ganska funktionellt även i C#

Exempel från min domän på jobbet
Kod:
public class RefundStrategy : IAmountDeviationStrategy
{
   public AmountDeviationStrategy Strategy => AmountDeviationStrategy.Refund;

   public PaymentInvoiceMatchResult Execute(MatchJob job)
   {
       if (job.Diff < 0)
           return new PaymentInvoiceMatchResultBuilder(job)
               .PaymentCategory(PaymentCategory.WrongPayment)
               .RefundAll(RefundReason.UnderPaid);

       var invoiceAmount = Math.Abs(job.Invoice.Amount);
       var payingPayments = GetPaymentsComboClosestToInvoiceAmount(job.Payments, invoiceAmount);

       var refunds = job.Payments.Except(payingPayments).ToList();
       var result = new PaymentInvoiceMatchResultBuilder(job, refunds)
           .PaymentCategory(PaymentCategory.WrongPayment)
           .Refund(refunds);

       if (payingPayments.Sum(p => p.Amount) != invoiceAmount)
           result.Refund<RefundSplitPaymentCommand>(payingPayments.First(p => p.Amount >= job.Diff), split => split.Amount = payingPayments.Sum(p => p.Amount) - invoiceAmount);

       return result
           .QueueCommand(new MapInvoicePaymentsCommand { InvoiceId = job.Invoice.ExternalId, Payments = payingPayments.Select(p => p.ExternalId) });
   }

   private IReadOnlyCollection<IPaymentMatchInfo> GetPaymentsComboClosestToInvoiceAmount(IReadOnlyCollection<IPaymentMatchInfo> payments, decimal invoiceAmount)
   {
       var combos = Enumerable.Range(1, payments.Count)
           .SelectMany(i => new Combinations<IPaymentMatchInfo>(payments, new ReferenceCompare<IPaymentMatchInfo>(), i))
           .ToList();

       var payingPayments = combos
           .Where(c => c.Sum(p => p.Amount) >= invoiceAmount)
           .OrderBy(combo => Math.Abs(combo.Sum(p => p.Amount) - invoiceAmount))
           .First();

       return payingPayments;
   }
Jo, men att slippa klasser, stark typning och ärvning är ju så skönt (eftersom nyttan av det ofta är väldigt begränsad i Micro-services) men det krävs förstås en annan disciplin, djupare förståelse och riktlinjer för att det inte ska spåra ur.
Pratar om Node.js då, men gäller ju alla skriptbaserade språk.
 
anders07 anders07 skrev:
Jo, men att slippa klasser, stark typning och ärvning är ju så skönt (eftersom nyttan av det ofta är väldigt begränsad i Micro-services) men det krävs förstås en annan disciplin, djupare förståelse och riktlinjer för att det inte ska spåra ur.
Tycker statisk typning fortfarande har ett syfte även i microservices.

I UI är det nice med dynamisk typning dock, alltså nära metallen tex när man databinder modellen mot UI. I C# blir det fult som fan med reflection.

Jag gillar Angular där runtime är dynamiskt typat men domänen kan köra statiskt typat via typescript.
 
Redigerat:
AndersMalmgren AndersMalmgren skrev:
Tycker statisk typning fortfarande har ett syfte även i microservices.

I UI är det nice med dynamisk typning dock, alltså nära metallen tex när man databinder modellen mot UI. I C# blir det fullt som fan med reflection.

Jag gillar Angular där runtime är dynamiskt typat men domänen kan köra statiskt typat via typescript.
Agreed! Vi kör Angular frontend och Node.js/GraphQL backend.

Ibland önskar man en starkare typning i Node.js, speciellt för att slippa så komplett/komplex validering men allt gott för väl något ont med sig...
 
  • Gilla
AndersMalmgren
  • Laddar…
A Alfons3301 skrev:
Ibland funderar jag på byta yrkesinriktning. Programmering är ett val som dyker upp då. Jag har inte gjort det sedan c64/Amigan när man provade på och sedan i gymnasiet på 90-talet. Det jag har arbetat mkt med är Excel, men då med enklare databashantering, PoweQuery osv.
Om jag skulle välja ett programmeringsspråk att börja lära mig, kan ni rekommendera vilket och varför?
Jag skulle säga Python utan att vara nån expert. Men jag tycker just Python dyker upp både här och där nuförtiden. Det ser ju ut lite som C detta Python tycker jag?
 
anders07 anders07 skrev:
Agreed! Vi kör Angular frontend och Node.js/GraphQL backend.

Ibland önskar man en starkare typning i Node.js, speciellt för att slippa så komplett/komplex validering men allt gott för väl något ont med sig...
Så är det. Man måste ha bra tester. Det måste man ju iof även i statiskt typade språk.

Ni kan köra typescript i nodejs
 
H håbbe1961 skrev:
Jobben inom IT o utveckling fasas ut för Sveriges del till förmån för låglöneländer ex Indien Spanien, Tjeckien mfl länder. Jobbat själv inom IT i 20år som sql specialist. Min son framgångsrik fullstack programmerare men redan som 30 åring insett att man måste redan byta bana till administratör
Jag delar inte den bilden. Den erfarenhet jag har av sådan outsourcing är att uppdragen oftast behöver vara så oerhört detaljspecade och att det blir så många turer fram och tillbaka för att rätta sådant som borde varit självklart för en utvecklare, att det går snabbare att koda själv. Men visst, en del företag kollar ju bara på timpris.

Möjligen kan det vara ett alternativ till svenska konsulter som ändå inte har någon verksamhetskunskap, men i min värld är det inte ett realistiskt alternativ till att ett företag har egna utvecklare.

Jag tror inte att vi behöver oroa oss över våra jobb av den anledningen.
 
  • Gilla
Boilerplate4U och 1 till
  • Laddar…
Boilerplate4U
Det finns också ett stort sug på på marknaden efter verksamhetsutvecklare som kan anamma konceptet "Low-code". Där är ålder och verksamhetskunskap en större tillgång än erfarenhet i programmering.

Low-code innebär att den traditionella programmeringen till stor del ersätts med en bygglåda med färdigintegrerade komponenter. Det göra att man kan sätta sig direkt tillsammans med verksamheten och löpande utveckla nya stödfunktioner i en BPR-liknade process som kan driftsättas på en bråkdel av tiden jämfört med traditionell systemutveckling. Väldigt likt när QlikView stormade in ekonomiavdelningarna och kunde skippa IT-avd som ville ha veckor bara för att bygga några kuber.

Det är en trend som växt sig väldigt stark de senaste åren och älskas i synnerhet av verksamhet som har problem de interna IT-leveranserna.
 
Begreppet "fullstackprogrammerare" ger mig rysningar.
Det är som allmänläkare, man kan lite av varje men är inte riktig expert på något.
 
  • Gilla
guggen
  • Laddar…
M MagHam skrev:
Begreppet "fullstackprogrammerare" ger mig rysningar.
Det är som allmänläkare, man kan lite av varje men är inte riktig expert på något.
Låter precis som experterna i detta forum
 
  • Gilla
  • Haha
PappasHammare och 4 till
  • Laddar…
Boilerplate4U
H håbbe1961 skrev:
Låter precis som experterna i detta forum
Touché! :rofl:
 
Vi vill skicka notiser för ämnen du bevakar och händelser som berör dig.