14 260 läst ·
182 svar
14k läst
182 svar
Välja programmeringsspråk
VA? Ålder har väl inte något med det att göra... Intresse däremot!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.
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.
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örA 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.
Renoverare
· Stockholm
· 20 191 inlägg
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#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.
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;
}
Då söker man åtminstone inte jobb i Stockholm... Här är det huggsexa om alla programmerare!H håbbe1961 skrev:
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...
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.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; }
Pratar om Node.js då, men gäller ju alla skriptbaserade språk.
Renoverare
· Stockholm
· 20 191 inlägg
Tycker statisk typning fortfarande har ett syfte även i microservices.anders07 skrev:
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:
Agreed! Vi kör Angular frontend och Node.js/GraphQL backend.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.
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...
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?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?
Renoverare
· Stockholm
· 20 191 inlägg
Så är det. Man måste ha bra tester. Det måste man ju iof även i statiskt typade språk.anders07 skrev:
Ni kan köra typescript i nodejs
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.H håbbe1961 skrev:
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.
Boilerplate4U
Medlem
· CEO Tomteverkstan Nordpolen
· 2 414 inlägg
Boilerplate4U
Medlem
- CEO Tomteverkstan Nordpolen
- 2 414 inlägg
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.
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.
