This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-04-29
Channels
- # babashka (30)
- # beginners (207)
- # biff (3)
- # calva (10)
- # cljs-dev (3)
- # clojure (34)
- # clojure-austin (3)
- # clojure-bay-area (1)
- # clojure-dev (3)
- # clojure-europe (31)
- # clojure-nl (1)
- # clojure-norway (37)
- # clojure-uk (8)
- # community-development (3)
- # core-async (4)
- # data-science (1)
- # dev-tooling (2)
- # emacs (4)
- # etaoin (12)
- # fulcro (7)
- # gratitude (1)
- # hyperfiddle (7)
- # jobs-discuss (191)
- # lsp (15)
- # malli (1)
- # other-languages (11)
- # overtone (1)
- # pathom (3)
- # pedestal (1)
- # polylith (21)
- # releases (1)
- # squint (5)
- # yamlscript (5)
Ref. tidligere diskusjoner om det å jobbe som konsulent på timesbasis vs. å ta betalt for den reelle verdien av sluttproduktet (uahvengig av hvor lang tid det tar å lage). Tanker? https://youtube.com/shorts/S98s1Gd53y4
Dog føler jeg det hadde vært mer ærlig og korrekt å ta betalt for verdien man faktisk tilfører. Da er insentivene bedre plassert. Men, ja, vanskeligere å gjennomføre på mange måter.
Jeg mener: 1. Å outsource hele teknologiorganisasjonen din er kjempedumt, det kommer du til å brenne deg på. 2. Når du ikke har outsourcet hele teknologiorganisasjonen din (du har ansatte utviklere), tror jeg det kan funke bra å leie inn folk til å jobbe på timesbasis — fordi da kan man faktisk snakke sammen om kvalitet utover det som synes i nettleseren til sluttbrukeren. 3. Hvis konsulent-innleie skal funke bra, må samarbeidet mellom innleide og ansatte være godt.
Det er ganske stor risiko å ta ved å ta betalt for leveranser. Din lønn blir fort veldig uforutsigbar, med mindre du er helt magisk når det kommer til estimering. Nå er det vel ikke så mange som vil ta ting på målpris eller liknende lenger heller. Det fører ofte til at man overestimerer voldsomt for å sikre seg.
Det er ganske stor risiko å ta ved å ta betalt for leveranser. Din lønn blir fort veldig uforutsigbar, med mindre du er helt magisk når det kommer til estimering.Og risikoen blir fordelt ujevnt: programmereren tar hele nedesiden (ingen betaling hvis ting skjærer seg) uten å få noe av oppesiden (du får ikke mer penger enn avtalt fastpris hvis kvaliteten blir høyrere en forventet).
Målpris er jo litt spesielt, man får gjerne et tillegg i timeprisen om du kommer under estimatet.
så programmereren er insentivert til å levere akkurat nok og bruke så kort som mulig tid? Høres ut som det kan føre til snarveier i koden.
Ja, og da blir det gjerne noe slags kvantitative "kvalitetsmål", som prosent av linjer med testdekning.
Når man fakturerer timer er det vel best å bruke så mye tid som mulig og gjøre en dårlig jobb sånn at man senere kan fakturere mange timer for vedlikehold 🤪
Derfor må man ha social engineers (selgere) som kan fortelle kunden hvor kompliserte problemene deres er og at vi faktisk bruker veldig lite tid 😝
Jeg må fremheve at jeg bare troller og kødder nå, i tilfelle det ikke var tydlig nok 😅
Men, jeg har dessverre observert noe som ligner ganske mye på den forretningsmodellen.
Ikke sant — det er helt komisk, fram til du snakker med en person som oppriktig jobber sånn og faktisk synes det er ok.
Jeg ser for meg (og har hatt) samtaler som dette med kunder om timesbasert arbeid: "Hei! Kan du fortelle meg om problemet ditt?" "Åh, det er sånn og sånn. Og litt sånn." "Aha! Hvis jeg hadde fikset det i dag, hvor mye vil du spart/hvor mye mer vil du tjent?" "Hmmm. Litt usikker. Kanskje 200.000 kr per måned? Noe sånt." "Skjønner! Hvor mye haster det?" "Det har vært sånn lenge og haster egentlig ikke så veldig. Men hver måned det ikke er fikset er jo penger tapt." "Jeg tror vi kan fikse det på ca. 3-6 måneder med tre personer. Hva tenker du om det?" "Det hadde vært helt supert, ja!" "Da kommer prisen på ca. 2-4 MNOK. Investeringen vil være spart inn innen ca. 10-20 måneder. Hva tenker du om det?" "Ja, bra! Kjør på." Da har man en ramme (3-6 md. og 2-4 MNOK) for å løse problemet innenfor.
jeg kan ingenting om geo-greier. Spør heller @U066L8B18, han er kjempegod på geografi!
Anyway @U07FCNURX please let me know if I can help somehow.
Sadly, that’s not something I’ve ever written, and I also don’t think I have the necessary skills!
@U066L8B18 I am currently trying to (naively) place a geo location within a 2D polygon (without holes) from a set of other geo locations. ChatGPT suggested using https://github.com/locationtech/jts - or the cool new geo-project from @teodorlu 😅 - if you have any suggestions for clojure libs or some such, I would be happy to hear them!
Nice.
The old Factual/geo
library wraps a few of the relevant JVM libraries including JTS.
https://github.com/Factual/geo/
Recently we've started writing tutorials using it.
• https://scicloj.github.io/clojure-data-scrapbook/projects/geography/seattle-parks/index.html
• https://scicloj.github.io/clojure-data-scrapbook/projects/geography/chicago-bikes/index.html
(sharing them here just to give an idea of a few of the things which are possible)
I'd be glad to look together if that helps. A bit busy now, but starting from about Thursday, time will be more flexible.