Het freelance (ICT-ers) discussie topic

[Freeaqingme]

Afas schreef op donderdag 1 juli 2021 @ 10:25:
Ik verwacht dat het - via tussenpersonen - niet al te ingewikkeld moet zijn om aan een opdracht te komen. In mijn werkveld zijn de tekorten net als in de ICT aanzienlijk. Qua tarief verwacht ik zo ongeveer €100-110 per uur te kunnen vragen.

Wat voor activiteiten of expertise heb je dat je een dergelijk tarief vraagt? Het is niet extreem hoog, maar zit wel richting de bovenkant van de markt. Daar is zeker ook wel ruimte, maar het is wel net wat lastiger om een opdracht te vinden. Zeker als je een tussenpersoon hebt die er ook nog wat vanaf wil snoepen.

Als je verwacht fulltime te gaan freelancen kom je uit op een jaaromzet van >144K (100*36*40 **). Dat is mijns inziens voldoende om te overwegen voor een BV te gaan ipv een eenmanszaak.

offtopic:
** 100 euro / uur * 36 uur per week * 40 weken per jaar

[ Voor 3% gewijzigd door Freeaqingme op 01-07-2021 10:29 ]

[Hydra]

Afas schreef op donderdag 1 juli 2021 @ 10:25:
Qua tarief verwacht ik zo ongeveer €100-110 per uur te kunnen vragen.

Wat doe je dan precies?

Dan over de te zetten stappen:
- inschrijven KvK
- zakelijke bankrekening openen
- boekhouder of accountant regelen
- zakelijk telefoonnummer regelen
- inschrijven diverse platforms voor opdrachten en contact leggen met tussenpersonen
- AOV afsluiten
- bedrijfsaansprakelijkheidsverzekering afsluiten

Is dit behalve het regelen van een opdracht ongeveer waar ik aan moet denken om te kunnen starten?

Het enige wat ook maar enigzins 'lastig' is, is het regelen van een klus. De rest stelt weinig voor. Je moet wel zsm een KvK inschrijving regelen want voor vrijwel alles heb je een KvK nummer nodig. Maar de rest stelt niet zo veel voor en veel dingen kan je prima een stuk later regelen. BTW aangifte is heel simpel dus pas bij je eerste IB aangifte is een boekhouder handig als je het niet zelf wil doen. Zakelijk nummer heb ik niet. Zakelijke bankrekeningen wel. BAV is vaak ene vereiste als je een klus aanneemt, maar ook het werk niet. Verder is het wel handig om iets te hebben om je uren te tracken en facturen te sturen enzo. Ik gebruik zelf MoneyMonk en ben daar erg tevreden over.

[pirke]

@Afas Vergeet geen mooi logo en visitekaartjes te regelen

[Afas]

Freeaqingme schreef op donderdag 1 juli 2021 @ 10:29:
[...]


Wat voor activiteiten of expertise heb je dat je een dergelijk tarief vraagt? Het is niet extreem hoog, maar zit wel richting de bovenkant van de markt. Daar is zeker ook wel ruimte, maar het is wel net wat lastiger om een opdracht te vinden. Zeker als je een tussenpersoon hebt die er ook nog wat vanaf wil snoepen.

Als je verwacht fulltime te gaan freelancen kom je uit op een jaaromzet van >144K (100*36*40 **). Dat is mijns inziens voldoende om te overwegen voor een BV te gaan ipv een eenmanszaak.

offtopic:
** 100 euro / uur * 36 uur per week * 40 weken per jaar

Ik wil op dit moment niet al te veel zeggen over wat ik precies doe, omdat ik nog aan het oriënteren ben. Om er iets richting aan te geven: Het gaat om coördinatie bij de overheid. Ik heb een redelijk beeld van de tarieven omdat ik regelmatig offertes voorbij zie komen van externe inhuur.

Meeste opdrachten liggen tussen de 24-32 uur. Rechtsvorm heb ik me nog niet echt mee bezig gehouden. Impliciet ging ik er van uit dat starten als eenmanszaak voor de hand ligt om dan eventueel later over te schakelen.

[tug3506]

Afas schreef op donderdag 1 juli 2021 @ 10:25:
Is dit behalve het regelen van een opdracht ongeveer waar ik aan moet denken om te kunnen starten?

Naast een bedrijfsaansprakelijkheidsverzekering (AVB) mogelijk ook een Beroepsaansprakelijkheidsverzekering (BAV)
En daarnaast ook handig vast eens na te denken hoe je jouw pensioen wilt gaan regelen.

Heb zelf de BAV, AVB, pensioen en AOV via een tussenpersoon/ financieel adviseur afgesloten die het allemaal heeft uitgezocht.

[page404]

pirke schreef op donderdag 1 juli 2021 @ 10:37:
@Afas Vergeet geen mooi logo en visitekaartjes te regelen

Visitekaartjes heb ik toevallig gisteren binnen gekregen. Na anderhalf jaar ook een keer de tijd voor genomen!

[rool]

Normaal gesproken zou ik nooit een half jaar nonstop hebben doorgewerkt, ik kan het niemand aanraden. Hopelijk gaat het in de tweede helft van het jaar een stuk rustiger worden.

De situatie was uitzonderlijk. Iemand moest toch die CoronaCheck app bouwen. Vannacht ging de europeese variant live, even een paar dagen rust voor me (en dan de bugs oplossen).

[Afas]

tug3506 schreef op donderdag 1 juli 2021 @ 10:40:
[...]


Naast een bedrijfsaansprakelijkheidsverzekering (AVB) mogelijk ook een Beroepsaansprakelijkheidsverzekering (BAV)
En daarnaast ook handig vast eens na te denken hoe je jouw pensioen wilt gaan regelen.

Heb zelf de BAV, AVB, pensioen en AOV via een tussenpersoon/ financieel adviseur afgesloten die het allemaal heeft uitgezocht.

Pensioen is wel belangrijk. Wat ik daarbij overweeg is om voorlopig bij mijn huidige pensioenfonds te blijven. Die bieden een faciliteit om tot maximaal 10 jaar ZZP'en deel te nemen. Dat geeft dan tijd om het uit te gaan zoeken. Het biedt ook de flexibiliteit om 25, 50 of 100% van de huidige pensioenopbouw voort te zetten.

[ID-College]

920 uur hier.. Hebben jullie niets beters te doen ofzo? Ik vind dat al (te)veel om eerlijk te zijn Doe liever leuke dingen ipv werken!

[jadjong]

rool schreef op donderdag 1 juli 2021 @ 10:45:
Normaal gesproken zou ik nooit een half jaar nonstop hebben doorgewerkt, ik kan het niemand aanraden. Hopelijk gaat het in de tweede helft van het jaar een stuk rustiger worden.

De situatie was uitzonderlijk. Iemand moest toch die CoronaCheck app bouwen. Vannacht ging de europeese variant live, even een paar dagen rust voor me (en dan de bugs oplossen).

Had je bij zo'n groot project niet een tweede mannetje mogen regelen?

[jadjong]

ID-College schreef op donderdag 1 juli 2021 @ 10:49:
920 uur hier.. Hebben jullie niets beters te doen ofzo? Ik vind dat al (te)veel om eerlijk te zijn Doe liever leuke dingen ipv werken!

Precies mijn mening, maar nu ik zelf kijk zit ik na 25 weken ook al op 1002 uur.

[Bulder]

Zijn uren voor jullie ook echt uren? Ik werk zelf met vaste deliverables voor X uur, maar het gebeurt nog wel eens dat ik zo'n proces gaandeweg wat efficiënter weet te maken of te automatiseren. Heb zo nu en dan wel eens een dag met 14 facturabele uren, terwijl ik zeker niet zo lang op kantoor zit.

[miena21]

Bulder schreef op donderdag 1 juli 2021 @ 11:12:
Zijn uren voor jullie ook echt uren? Ik werk zelf met vaste deliverables voor X uur, maar het gebeurt nog wel eens dat ik zo'n proces gaandeweg wat efficiënter weet te maken of te automatiseren. Heb zo nu en dan wel eens een dag met 14 facturabele uren, terwijl ik zeker niet zo lang op kantoor zit.

Haha hier kan ik alleen maar van dromen. 2 uur werken en dan 8 uur kunnen schrijven. Helaas werkt dat niet zo in ontwikkelaarsland. Passief inkomen is perfect

[Deveon]

Bulder schreef op donderdag 1 juli 2021 @ 11:12:
Zijn uren voor jullie ook echt uren? Ik werk zelf met vaste deliverables voor X uur, maar het gebeurt nog wel eens dat ik zo'n proces gaandeweg wat efficiënter weet te maken of te automatiseren. Heb zo nu en dan wel eens een dag met 14 facturabele uren, terwijl ik zeker niet zo lang op kantoor zit.

Helaas werkt dat bij mij niet zo. Maar heb jij dan specifieke afspraken hoeveel uur je mag schrijven per proces? Ik schrijf namelijk alleen de uren dat ik werk en als dat efficiënter is dat winst voor de klant en als het langer duurt risico voor de klant.

[c-nan]

Jullie werken veel!

Hier 871 declarable uren 01-01 t/m 01-07.

Straks 3-4 weken op vakantie

[MadEgg]

Ik zit op 966 facturabele uren in 2021, voor 4 verschillende klanten. Maar meer dan 40 uur per week werken zit er bij mijn "hoofdklanten" niet in, niet structureel in ieder geval. Er is budget voor 40 uur, dus ik word niet geacht daar al te veel overheen te gaan. De ene week een paar uur meer en de andere een paar uur minder is uiteraard geen probleem.

Die 966 vind ik ook wel genoeg. Te veel eigenlijk. Ik dit halfjaar heb ik twee weken vakantie gehad. Ik vind het leuk en interessant om voor voorgaande klanten klussen te blijven doen, en goed voor mijn klantrelaties. Maar wat vaker nee zeggen zou wel goed zijn, want aan klussen in/om het huis kom ik amper toe. Gelukkig kan ik met relatief weinig slaap toe anders zou ik naast mijn gezin echt geen vrije tijd over hebben.

[Woy]

c-nan schreef op donderdag 1 juli 2021 @ 11:47:
Jullie werken veel!

Hier 871 declarable uren 01-01 t/m 01-07.

Straks 3-4 weken op vakantie

Ik maar 830, maar heb in maart bewust even een maandje erg rustig aan gedaan.

[Bulder]

Deveon schreef op donderdag 1 juli 2021 @ 11:39:
[...]

Helaas werkt dat bij mij niet zo. Maar heb jij dan specifieke afspraken hoeveel uur je mag schrijven per proces? Ik schrijf namelijk alleen de uren dat ik werk en als dat efficiënter is dat winst voor de klant en als het langer duurt risico voor de klant.

Ja, maar dan heb ik het echt over kleine deliverables van 6 uur per stuk of iets dergelijks. Als iets langer duurt is dat risico juist voor mij overigens, maar dat gebeurt heel weinig. Op 6 uur kun je je natuurlijk moeilijk verrekenen.

Denk aan een dashboardje bouwen of iets dergelijks. Die eerste keer kost me zeker zoveel uur, maar als er een soortgelijke klant komt kan ik gewoon dupliceren en de connectors vervangen, en dan ben ik klaar. De klant krijgt nog steeds evenveel waarde, maar het feit dat ik toevallig al eerder iets soortgelijks gebouwd heb moet mijn voordeel zijn, en niet die van de klant.

[jadjong]

Om het vergelijkbaar te houden met loondienst reken ik altijd met 1880 werkbare uren per jaar. Daar trek ik dan overhead van af zoals administratie doen of een cursus volgen. Wat daar van over blijft zijn maximaal declarabele uren. Als je daarmee meer dan genoeg geld verdiend kan je minder gaan werken voor je eigen plezier, als je niet genoeg geld verdiend is het misschien beter om iets anders te gaan doen.
Uiteraard gaat het wel eens mis zoals het afgelopen half jaar waar ik meer heb gewerkt om mensen (en mijzelf) tevreden te stellen, maar het moet niet meegroeien met je uitgavepatroon. Dan wordt het structureel en dat is niet gezond.

[pirke]

885 declarabel hier, dat vind ik al teveel

[ralpje]

Bulder schreef op donderdag 1 juli 2021 @ 12:23:
[...]


Ja, maar dan heb ik het echt over kleine deliverables van 6 uur per stuk of iets dergelijks. Als iets langer duurt is dat risico juist voor mij overigens, maar dat gebeurt heel weinig. Op 6 uur kun je je natuurlijk moeilijk verrekenen.

Overigens naar mijn mening ook een prima manier om van de 'dienstverband' discussie af te komen.
Ik neem een opdracht aan met een bepaalde deliverable (of dat nou het bouwen van een dashboard, het schrijven van een stuk software of het migreren van een Exchange-omgeving is) en daar hangt een prijs aan. Die prijs baseer ik uiteraard op mijn verwachting van de hoeveelheid werk, maar is een fixed price. Of je dat vervolgens in 1, 20, 150 of 4000 uur doet, maakt dan niet meer uit. Je levert een dienst en daar staat een prijs tegenover. Je hebt ook geen overeenkomst meer voor x-uur (of x-maanden), maar tot de deliverable is opgeleverd.

Vraag uiteraard wel om strak weer bij het opstellen van de offerte / overeenkomst en het goed bepalen wat in / uit scope is (en hoe je omgaat met onvoorziene situaties) om te voorkomen dat je er teveel op leegloopt, maar ook dat is een kwestie van ervaring.

Ik doe nog wel eens assesments van Azure / M365 omgevingen, om te zien of men aan de best practices voldoet, of er op security vlak iets te winnen valt, geld te besparen valt, etc. Dat is een fixed price ding, wat overeenkomt met twee a drie dagen werk. Op de achtergrond is dat natuurlijk geautomatiseerd in een stapel PowerShell scripts en hoef ik de output daarvan alleen maar in een standaard rapport-sjabloon te gieten

[MadEgg]

ralpje schreef op donderdag 1 juli 2021 @ 13:05:
[...]


Overigens naar mijn mening ook een prima manier om van de 'dienstverband' discussie af te komen.
Ik neem een opdracht aan met een bepaalde deliverable (of dat nou het bouwen van een dashboard, het schrijven van een stuk software of het migreren van een Exchange-omgeving is) en daar hangt een prijs aan. Die prijs baseer ik uiteraard op mijn verwachting van de hoeveelheid werk, maar is een fixed price. Of je dat vervolgens in 1, 20, 150 of 4000 uur doet, maakt dan niet meer uit. Je levert een dienst en daar staat een prijs tegenover. Je hebt ook geen overeenkomst meer voor x-uur (of x-maanden), maar tot de deliverable is opgeleverd.

Vraag uiteraard wel om strak weer bij het opstellen van de offerte / overeenkomst en het goed bepalen wat in / uit scope is (en hoe je omgaat met onvoorziene situaties) om te voorkomen dat je er teveel op leegloopt, maar ook dat is een kwestie van ervaring.

Ik doe nog wel eens assesments van Azure / M365 omgevingen, om te zien of men aan de best practices voldoet, of er op security vlak iets te winnen valt, geld te besparen valt, etc. Dat is een fixed price ding, wat overeenkomt met twee a drie dagen werk. Op de achtergrond is dat natuurlijk geautomatiseerd in een stapel PowerShell scripts en hoef ik de output daarvan alleen maar in een standaard rapport-sjabloon te gieten

Ik zou het ook niet erg vinden om betaald te worden per story points in de sprint. Met team bespreken we de punten en ik committeer me dan aan deze punten, en krijg per story point betaald. Ik verwacht alleen dat dit de complex wordt voor de meeste (grotere) klanten, die hebben gewoon een vast budget. Eigenlijk maakt het ze ook bar weinig uit of ik de uren maak, zolang collega's, stakeholders en manager maar tevreden zijn over mijn output.

[pirke]

MadEgg schreef op donderdag 1 juli 2021 @ 13:34:
[...]


Ik zou het ook niet erg vinden om betaald te worden per story points in de sprint. Met team bespreken we de punten en ik committeer me dan aan deze punten, en krijg per story point betaald. Ik verwacht alleen dat dit de complex wordt voor de meeste (grotere) klanten, die hebben gewoon een vast budget. Eigenlijk maakt het ze ook bar weinig uit of ik de uren maak, zolang collega's, stakeholders en manager maar tevreden zijn over mijn output.

Dat geldt ook voor het vaste personeel: zo lang de sprint doelen gehaald worden en iedereen is happy met de output van het team maakt het ook weinig uit.

[sverzijl]

MadEgg schreef op donderdag 1 juli 2021 @ 13:34:
[...]


Ik zou het ook niet erg vinden om betaald te worden per story points in de sprint.

Lijkt me ook niet echt werken. Storypoints zullen dan ineens heel erg conservatief ingeschat worden, want niemand durft er zijn vingers meer aan te branden dan

[Woy]

MadEgg schreef op donderdag 1 juli 2021 @ 13:34:
[...]


Ik zou het ook niet erg vinden om betaald te worden per story points in de sprint. Met team bespreken we de punten en ik committeer me dan aan deze punten, en krijg per story point betaald. Ik verwacht alleen dat dit de complex wordt voor de meeste (grotere) klanten, die hebben gewoon een vast budget. Eigenlijk maakt het ze ook bar weinig uit of ik de uren maak, zolang collega's, stakeholders en manager maar tevreden zijn over mijn output.

Dat is ook een disaster waiting to happen, wordt ook afgeraden om story points voor dat soort metrics te gebruiken, want maakt het op termijn bijna altijd onwerkbaar.

Anders krijg je zoiets

[MeZZiN]

Voor mij dit jaar al weer 987 uur gemaakt (moet wat inhalen met vorige jaar 4 maanden even niets gehad) Maar het tweede deel zit wel vakanties in gelukkig.

Verder voor mij is alles uurtje factuurtje en dat is wel zo prima zeker omdat alles lijkt uit te lopen of complexer is dan het zou moeten.

[MadEgg]

sverzijl schreef op donderdag 1 juli 2021 @ 13:41:
[...]

Lijkt me ook niet echt werken. Storypoints zullen dan ineens heel erg conservatief ingeschat worden, want niemand durft er zijn vingers meer aan te branden dan

En daarmee wordt je velocity flink verstoord - als de story points hoger zijn terwijl de taken gelijk blijven dan gaat je velocity dus kunstmatig omhoog. Dat zou toch ook alarmbellen moeten laten afgaan.

Story points wordt in mijn teams over algemeen gebruikt als een soort van urenraming. Ik heb veel vaker klussen op projectbasis gedaan waarbij ik vooraf mijn uren inschat en vervolgens het als vaste prijs afspreek met de klant. Duurt het langer heb ik pech, duurt het korter heb ik mazzel. De klant weet precies waar hij aan toe is. Beviel van beide kanten prima. Als je in een team van profiteurs zit dan werkt het niet, als je sowieso al je best doen om redelijke schattingen te maken dan werkt het prima.

Uren schrijven is net zo goed riskant, maar dan met name voor de klant. De ene dag is de andere dag niet, de ene dag ben je niet even productief als de andere. Zo werkt het voor mij in ieder geval. Ik heb zelf dus een voorkeur voor resultaatverplichting boven inspanningsverplichting, en zo wordt het vanuit de DBA e.d. ook gezien. Alleen klanten hebben er weinig trek in.

[Tsjilp]

Kom ik aan met m'n 656 uren 😬, maar ja, ik leef niet om te werken 😊

[hackerhater]

Well we konden toch nergens heen met Covid.
En partner-lief gaat vanaf september weer studeren en dat kost een hoop poen.

[Tsjilp]

Dat is natuurlijk niet helemaal waar, ik heb namelijk nog nooit zoveel op de racefiets gezeten als dit jaar

[sverzijl]

Tsjilp schreef op donderdag 1 juli 2021 @ 15:06:
Kom ik aan met m'n 656 uren 😬, maar ja, ik leef niet om te werken 😊

Mijn werk voelt meer als hobby, en krijg er ook nog eens (veel te goed, ssst) voor betaald. Wat wil je nog meer

[Aftansert]

Een half jaar werken, en anderhalfjaar daarna lekker rustig werken aan eigen projectjes is ook niets mis mee. Met een beetje geluk rolt daar ook nog een leuk project uit met wat passief inkomen, maar dat hoeft niet perse.

[ Voor 33% gewijzigd door Aftansert op 01-07-2021 19:31 ]

[ybos]

sverzijl schreef op donderdag 1 juli 2021 @ 15:12:
[...]

Mijn werk voelt meer als hobby, en krijg er ook nog eens (veel te goed, ssst) voor betaald. Wat wil je nog meer

Zo voelt t hier (meestal) ook.
Tot nog toe een kleine 1180 uur dit jaar.
Hier een grote investering eind augustus, en daarvoor het laatste anderhalf jaar gepakt wat ik pakken kan. Scheelt dat ik mijn werk leuk vind en een zeer flexibele vrouw die snapt dat ik t werk leuk vind en ook het doel van de investering snapt (passief inkomen).

Afgelopen 3 jaar aan vakantie gehad:
jaar -2: niets, hier en daar een vrije dag
jaar -1: weekje tenerife net voordat de corona uitbrak + weekendje weg
huidig jaar: weekend weg.

Wel pak ik zeer regelmatig tegenwoordig een middagje vrij voor de hobby dus ik begin het eindelijk een beetje te leren

[MeZZiN]

Ik heb ook erg weinig stress van mijn werk zeker sinds ik freelance ben. Ik werk nu wat meer om vorige jaar wat in te halen. Maar straks gewoon weer ongeveer 8 weken vrij hebben per jaar. Luxe in vergelijking met in dienst.

Maar goed mijn huidige klus was wat drukker dan normaal ik gewend ben maar ook met weekend diensten was toch wat druk. Gelukkig is de rust weer terug omdat iedereen weer in de winkel kan shoppen minder online bestellingen bij ons dus weer meer focus op development ipv brandjes blussen.

[ybos]

MeZZiN schreef op donderdag 1 juli 2021 @ 21:12:
Ik heb ook erg weinig stress van mijn werk zeker sinds ik freelance ben. Ik werk nu wat meer om vorige jaar wat in te halen. Maar straks gewoon weer ongeveer 8 weken vrij hebben per jaar. Luxe in vergelijking met in dienst.

Maar goed mijn huidige klus was wat drukker dan normaal ik gewend ben maar ook met weekend diensten was toch wat druk. Gelukkig is de rust weer terug omdat iedereen weer in de winkel kan shoppen minder online bestellingen bij ons dus weer meer focus op development ipv brandjes blussen.

Brandjes blussen kan ook leuk zijn
Persoonlijk vind ik storingen het mooiste wat er is (niet ICT). Vervelend voor de klant, maar zaken regelen, maken, zorgen dat de klant zijn business weer kan opstarten en daarmee een tevreden klant -> Mooiste wat er is, avond, nacht, hoe later hoe mooier (iets met vakidioot enzo )

[jadjong]

Zolang de klant niet doet alsof er mensenlevens op het spel staan heb ik ook wel lol in last-minute trouble shooten. Zeker als je alle (finaciele) ruimte en medewerking krijgt kan je op de meest ongemakkelijke rijden met een goes gevoel en vol energie naar bed.
Maar dan moeten ze niet vanaf de eerste minuut in je nek gaan hijgen en dramatische verhalen vertellen over hoeveel werk ze verliezen. Dat kan ik zelf ook wel bedenken.

[fry77]

793 uur facturabel tot nu toe, als dat zo doorgaat zit ik straks op bijna 1600 uur. Das wel meer dan mijn gemiddelde

[MeZZiN]

@ybos en @jadjong Beide gelijk het moet wel leuk blijven gelukkig was dit niet erg een ik kon het extra geld goed gebruiken dus no harm plus we hebben scrum die redelijk werkt dus waardoor we geen gedoe hebben met last minute zooi. En soms was er wel een aan avond door knutselen om het weer met ducktape even verder te helpen maar op zijn tijd is dat ook wel weer leuk om te doen. Plus een stuk dankbaarheid en begrip kom je een heel eind.

Stukken beter dan vroeger waarbij gewoon verwacht werd dat je een het weekend en avonden extra werkt omdat het er bij hoort. en dat je 's avonds na rond 9 uur naar huis gaat en dan nog krijgen waarom ga je nu al ik was al vanaf 8 uur op mijn werkplek nu ik freelance doe is het altijd elk uur betaald nog niet heel vaak extra maar goed geen gedoe over ongeschreven regels en verwachtingen.

Maar sta er toch altijd weer verbaast over hoe vaak ik code weg gooi / herschrijf die nog niet eens 3-5 jaar oud is omdat het gewoon zo bagger in elkaar zit. (meestal over de top complex) En als ik klaar ben dat er maar een fractie over is maar hetzelfde doet. Noem het altijd maar New Legacy Code snap er namelijk helemaal niets van dat moderne software nog steeds zo slecht in elkaar zit.

[pirke]

MeZZiN schreef op vrijdag 2 juli 2021 @ 08:37:

Maar sta er toch altijd weer verbaast over hoe vaak ik code weg gooi / herschrijf die nog niet eens 3-5 jaar oud is omdat het gewoon zo bagger in elkaar zit. (meestal over de top complex) En als ik klaar ben dat er maar een fractie over is maar hetzelfde doet. Noem het altijd maar New Legacy Code snap er namelijk helemaal niets van dat moderne software nog steeds zo slecht in elkaar zit.

Dat heeft iedereen met code van een ander, zo praten anderen weer over jou code

Elk hoofd heeft andere kronkels zullen we maar zeggen.

Mijn code is anders natuurlijk, ik schrijf wel GodenCode

[RonaldHeirbaut]

pirke schreef op vrijdag 2 juli 2021 @ 08:43:
[...]
Mijn code is anders natuurlijk, ik schrijf wel GodenCode

Aaaaah, dan is het leesbaar EN goed gedocumenteerd. Dusssss.

[pirke]

Het is ook een beetje de menselijke psyche: 90% vd werknemers vindt dat hij beter presteert dan een gemiddelde collega.

[MadEgg]

pirke schreef op vrijdag 2 juli 2021 @ 08:47:
Het is ook een beetje de menselijke psyche: 90% vd werknemers vindt dat hij beter presteert dan een gemiddelde collega.

Dan kan wel waar zijn, maar ik verwacht dat er bij (duurbetaalde) freelancers iets meer kwaliteit is dan bij de gemiddelde software engineer in dienst.

Ik krijg in ieder geval achteraf vaak genoeg complimenten over de structuur en documentatie in mijn code

[MeZZiN]

True maar er nooit een excuus voor slechte code ^_^ Daarom simpeler code is beter gedocumenteerd en beter leesbaar dus minder issues. Daarom uit de java wereld gestapt zo veel tijd bezig met opzetten en weinig coding. Plus java is toch bijna de nieuwe cobol.

en elke regel te veel is een groter risico op bugs. Plus als je het door sonar trekt zie je dat complexe code een slechte score.

Maar goed ik heb er een goed business model door bij de meeste klussen is het puin ruimen en dan weer netjes achterlaten.

[ Voor 13% gewijzigd door MeZZiN op 02-07-2021 08:52 ]

[RonaldHeirbaut]

pirke schreef op vrijdag 2 juli 2021 @ 08:47:
Het is ook een beetje de menselijke psyche: 90% vd werknemers vindt dat hij beter presteert dan een gemiddelde collega.

Neuh, 95% van de mensen presteert veel slechter dan ik.

Maar ik merk wel dat ik als ZZP-er soms te maken krijg met mensen (loondienst collega's) die wel een bepaalde klus moeten doen en naar mijn idee onvoldoende capaciteiten daarvoor hebben. Dan heb ik de neiging daar wat van te zeggen of het zelf dan maar even op te pakken of op te lossen. Dat heb ik intussen afgeleerd. Sommige dingen kan ik beter dan anderen maar ik wil anderen dan niet de kans ontnemen om even goed te worden als ik (of beter). Beetje begeleiding lever ik dan wel, eventueel.

[Remcoder]

MeZZiN schreef op vrijdag 2 juli 2021 @ 08:51:
Plus java is toch bijna de nieuwe cobol.

Oeh, dus nog even en ik kan ook 200 euro per uur rekenen voor mijn werk?

[MadEgg]

MeZZiN schreef op vrijdag 2 juli 2021 @ 08:51:
en elke regel te veel is een groter risico op bugs. Plus als je het door sonar trekt zie je dat complexe code een slechte score.

Sonar is wel een tikje opinionated in dat opzicht. Complexe code is niet altijd te vermijden en het alternatief is soms echt ondergeschikt aan een ietwat complexere implementatie.

Ik zit nu voor het eerst in mijn carrière in een team met twee andere engineers die naar mijn gevoel aardig op hetzelfde niveau zitten. Dat is wel heel prettig moet ik zeggen. In code reviews strijk je dan elkaars kronkels glad in plaats van dat je onbegrip moet opvangen of hele stukken code van anderen moet herschrijven.

[_Arthur]

Remcoder schreef op vrijdag 2 juli 2021 @ 08:59:
Oeh, dus nog even en ik kan ook 200 euro per uur rekenen voor mijn werk?

Nah, je bedoeld 40euro/uur omdat je nergens anders meer aan de bak komt

[Ernemmer]

Ik moet nog aan de bak dit jaar zie ik, 390 uur factureerbaar tot nu toe

[RichieB]

MeZZiN schreef op vrijdag 2 juli 2021 @ 08:51:
True maar er nooit een excuus voor slechte code ^_^ Daarom simpeler code is beter gedocumenteerd en beter leesbaar dus minder issues.
[...]

Simpele code is de documentatie. Als je in comments moet gaan uitleggen wat de code doet is je code niet simpel genoeg.

[page404]

Ik heb het eerste half jaar 830 uur gemaakt. Verwacht er niet meer dan 700 in de tweede helft te maken (ivm vakanties). is toch 130k omzet, ik denk dat dat wel genoeg is. Wordt toch hoog tijd dat ik het meer schaalbaar maak en mijn eigen services ga verkopen

[Lisper]

RichieB schreef op vrijdag 2 juli 2021 @ 10:19:
[...]

Simpele code is de documentatie. Als je in comments moet gaan uitleggen wat de code doet is je code niet simpel genoeg.

Ehm, documentatie is meer dan alleen comments, denk aan readmes, design docs, uitleg over waar je op met letten met deployments, etc.
Om helemaal nooit comments te gebruiken vind ik overdreven, een beetje uitleg hier en daar over waarom bepaalde keuzes zijn gemaakt is heel handig.

[MeZZiN]

Daarom is mijn code zonder comment en zonder uitleg behalve de readme die die precies uitlegt waar de code voor bedoeld is plus hoe hij in de architectuur past. Meer niet. De code moet zelf documenterend zijn. Anders is het te complex en moet het op de schop.

Plus mijn doel is altijd dat ik vervangbaar ben dan kan ik tenminste op vakantie zonder zorgen en onderbreken.

[thijs42]

pirke schreef op vrijdag 2 juli 2021 @ 08:43:
[...]
Dat heeft iedereen met code van een ander, [...]

Sterker nog, ik denk dat veel developers dit vaker dan eens zal hebben gehad met eigen code van een tijd geleden.

Vraag me af hoe vaak iemand `git blame` erbij pakt om te checken welke incompetent dit stukje code heeft geschreven om dan vervolgens te mompelen 'oeps' en dan stilletjes de rommel op te ruimen...

[MadEgg]

MeZZiN schreef op vrijdag 2 juli 2021 @ 11:24:
Daarom is mijn code zonder comment en zonder uitleg behalve de readme die die precies uitlegt waar de code voor bedoeld is plus hoe hij in de architectuur past. Meer niet. De code moet zelf documenterend zijn. Anders is het te complex en moet het op de schop.

Plus mijn doel is altijd dat ik vervangbaar ben dan kan ik tenminste op vakantie zonder zorgen en onderbreken.

Geen comments is een directe reject als ik je code zou reviewen. Maakt niet uit hoe simpel het is. Een one-liner-method moet nog steeds ene JavaDoc hebben (in het geval van Java) waarin staat wat de parameter zijn en wat de functie doet. Dat kan best in 5 woorden. Het is ook een extra vorm van sanity check / unit test. Je kunt controleren of de functie nog steeds doet waar hij voor ontworpen is, en als je hem wijzigt weet je ook wat er dan anders is.

Pagina's vol met comments is een red flag, dat zeker. Maar geen comments net zo goed.

[thijs42]

Lisper schreef op vrijdag 2 juli 2021 @ 11:18:
[...]
Ehm, documentatie is meer dan alleen comments, denk aan readmes, design docs, uitleg over waar je op met letten met deployments, etc.
Om helemaal nooit comments te gebruiken vind ik overdreven, een beetje uitleg hier en daar over waarom bepaalde keuzes zijn gemaakt is heel handig.

Precies dit. Comments moeten vertellen waarom bepaalde keuzes gemaakt zijn. Niet wat de code doet. Daar is de code voor...

Daarom geloof ik niet zo in developers die vol trots vermelden dat zij geen comments in hun code nodig hebben.

[hackerhater]

MadEgg schreef op vrijdag 2 juli 2021 @ 11:38:
Geen comments is een directe reject als ik je code zou reviewen. Maakt niet uit hoe simpel het is. Een one-liner-method moet nog steeds ene JavaDoc hebben (in het geval van Java) waarin staat wat de parameter zijn en wat de functie doet. Dat kan best in 5 woorden. Het is ook een extra vorm van sanity check / unit test. Je kunt controleren of de functie nog steeds doet waar hij voor ontworpen is, en als je hem wijzigt weet je ook wat er dan anders is.

Pagina's vol met comments is een red flag, dat zeker. Maar geen comments net zo goed.

Hier hebben we juist de regel dat we heel weinig PHPDoc toevoegen gecombineerd met strongly-typed parameters & return types.
We voegen PHPDoc alleen toe als het wat toe voegt zoals de @throws en dat die array toch echt een User[] type is.

Beetje nutteloos om te declareren dat die variabele een int is, terwijl de parameter een int-type heeft.
Uiteraard zijn niets-zeggende functie-namen of variabele-namen een reject.

[ Voor 3% gewijzigd door hackerhater op 02-07-2021 11:49 ]

[ANdrode]

thijs42 schreef op vrijdag 2 juli 2021 @ 11:40:
[...]

Precies dit. Comments moeten vertellen waarom bepaalde keuzes gemaakt zijn. Niet wat de code doet. Daar is de code voor...

Daarom geloof ik niet zo in developers die vol trots vermelden dat zij geen comments in hun code nodig hebben.

Dit gaat wel alleen op voor niet-triviale probleemdomeinen - als je web-agency werk doet dan niet:
Als je niet wilt documenteren en claimt "dat het duidelijk is door de namen" dan ben je technical debt aan het maken.

Minimaal opschrijven waarom. Als het niet direct duidelijk is ook de invarianten en pre- en postcondities.

offtopic:
"Ja maar je kan het afleiden": daar zitten interpretatieverschillen in én je verplaatst de cognitieve complexiteit naar je collegas.

"Ja maar de documentatie klopt soms niet meer": Dat doen de namen soms ook niet.

"Ja maar nu krijg ik geen 4 er voor en dit scheelt mij werk": dick move.

---

Wat ook nog een perspectief is: Je bent via code ook aan het communiceren met jezelf en teamgenoten, nu en in de toekomst. De context maakt uit en context in git commit messages verlies je na refactors/over tijd.

[ Voor 9% gewijzigd door ANdrode op 02-07-2021 12:10 ]

[MadEgg]

hackerhater schreef op vrijdag 2 juli 2021 @ 11:47:
[...]


Hier hebben we juist de regel dat we heel weinig PHPDoc toevoegen gecombineerd met strongly-typed parameters & return types.
We voegen PHPDoc alleen toe als het wat toe voegt zoals de @throws en dat die array toch echt een User[] type is.

Beetje nutteloos om te declareren dat die variabele een int is, terwijl de parameter een int-type heeft.
Uiteraard zijn niets-zeggende functie-namen of variabele-namen een reject.

Int toevoegen heeft weinig zijn, dat doet de compiler / interpreter wel voor je. Maar wat ik bijvoorbeeld heel vaak mis is in code / documentatie zijn eenheden. Is `duration` nou in seconden, milliseconden of microseconden? Of soms toch zelfs nanoseconden. Is `amount` nou in euro's, centen of bitcoin? Zo makkelijk om dat soort dingen gewoon even in de docs te zetten. Bovendien laat je IDE dergelijke docs zien in de interface, zonder dat je zelf naar de code hoeft te kijken.

[hackerhater]

MadEgg schreef op vrijdag 2 juli 2021 @ 12:14:
Int toevoegen heeft weinig zijn, dat doet de compiler / interpreter wel voor je. Maar wat ik bijvoorbeeld heel vaak mis is in code / documentatie zijn eenheden. Is `duration` nou in seconden, milliseconden of microseconden? Of soms toch zelfs nanoseconden. Is `amount` nou in euro's, centen of bitcoin? Zo makkelijk om dat soort dingen gewoon even in de docs te zetten. Bovendien laat je IDE dergelijke docs zien in de interface, zonder dat je zelf naar de code hoeft te kijken.

Daarom goede namen
Duration is inderdaad een slechte naam als de functie-naam het niet al duidelijk maakt. Die zou dan bijvoorbeeld durationInSeconds moeten heten.

[pirke]

Welkom in de wereld van embedded beeldverwerking, daar beginnen we eerst met welk assenstelsel is van toepassing? Y positief: is dat omhoog (wiskundig) of omlaag (image domein)? En is die dan ten opzichte vd logische of fysieke oriëntatie vd sensor? Zeker bij bewegende machines heel relevant. Leuk dat er een calibratie offset is, maar is dat een error of correctie? Scheelt ook weer 180 graden.

En zo krijg je namen als rotationInDegreesImageDomainPhysicalBlaBlaSensorCalibrationCorrectionOffset.

Echt, de complexiteit die bij rotaties en offsets komen kijken...

[MadEgg]

hackerhater schreef op vrijdag 2 juli 2021 @ 12:18:
[...]


Daarom goede namen
Duration is inderdaad een slechte naam als de functie-naam het niet al duidelijk maakt. Die zou dan bijvoorbeeld durationInSeconds moeten heten.

Wat @pirke zegt Je krijgt hele gekunstelde variabelenamen. `duration` is prima. In Java hebben we daar gelukkig de `Duration` class voor die de eenheid erbij in heeft, maar die wordt niet altijd gebruikt.

Variabelenamen als `durationInSeconds` zijn vervelend om mee te werken, en het kan nog veel complexer worden afhankelijk van wat de variabele precies voorstelt. Ik zie dan nog wel eens `duration_s` of `duration_ms` - dat is een redelijk compromis. Maar beter is gewoon de eenheid erbij te vermelden, dan ziet de caller het ook direct en kun je mooie API-docs genereren.

Anyway, dit gaat wel een beetje off-topic We hadden het erover wat een briljante code wij freelancers opleveren

[pirke]

@MadEgg Ik denk dat dienstverband of de gekozen rechtsvorm weinig uitmaakt voor de kwaliteit van de code van een ontwikkelaar

[hackerhater]

Ik ben nu bezig aan een stuk code wat ik oorspronkelijk heb geschreven en wat uitgebreid is door collega's.
Lees: functionaliteit erbij gehacked.

Ik heb nu dit gevoel:

[TucanoItaly]

Ik ben zo onderhand wel toe aan een nieuwe klus, en hou nu een aantal sites uit de start post in de gaten. Ik dacht er over om LinkedIn te gebruiken, maar weet niet zo goed hoe dat aan te pakken. Gewoon posten "ik ben beschikbaar voor een klus" gaat de huidige klant zien, plus ik wil bij voorkeur geen recruiter er tussen.

Heeft iemand hints wat LinkedIn betreft, of tips voor zoeken naar een nieuwe iOS (mobile dev) klus?

[MeZZiN]

Dat dus beperkte kennis of te veel kennis waardoor het complex wordt omdat er graag gebruikt wordt van patterns plus spekkoek code (layers because of layers).

Vaak wel dat je nette code maakt en iemand gaat er mee aan de haal en het is opeens extreem complex geworden en ze hebben alleen maar een bug gefixed.

Daarom help ik ze verder en simpeler maken en minder complex. Vaak neem ik de interne mee en begeleid ze ook. Vaak worden externe ook ingehuurd om kennis .

Mooiste was dat ik een oude klant vroeg voor referentie en daarna even vroeg hoe het met het project ging (was 3 jaar later) oh ja we hebben nog een paar bug gefixed na release maar verder de laatste 2 jaar niets aan gedaan.

[Remcoder]

TucanoItaly schreef op vrijdag 2 juli 2021 @ 13:11:
Ik ben zo onderhand wel toe aan een nieuwe klus, en hou nu een aantal sites uit de start post in de gaten. Ik dacht er over om LinkedIn te gebruiken, maar weet niet zo goed hoe dat aan te pakken. Gewoon posten "ik ben beschikbaar voor een klus" gaat de huidige klant zien, plus ik wil bij voorkeur geen recruiter er tussen.

Heeft iemand hints wat LinkedIn betreft, of tips voor zoeken naar een nieuwe iOS (mobile dev) klus?

Wanneer ben je dan van plan het aan je klant te melden?

Tenzij de relatie al verstoord is lijkt het mij niet handig om gebruik te maken van de opzegtermijn in je contract. Ik zou het dan eerder aangeven bij een verlenging dat het wat mij betreft de laatste verlenging is. Eventueel kan je er dan nog de reden bij opgeven, bv dat je het na x jaar wel tijd vindt om wat anders te gaan doen.

Dan weet de klant waar die aan toe is, en kan alvast op zoek gaan naar vervanging en jij kan gewoon zonder je zorgen te maken overal adverteren waar je maar wil.

Linksom, of rechtsom, ze gaan nooit blij zijn als je vertrekt, maar de manier waarop je het brengt maakt wel een groot verschil over hoe ze in de toekomst naar jou zullen kijken en over jou zullen vertellen.

[hackerhater]

Ik zou inderdaad ruim op tijd melden dat je niet gaat verlengen als je de huidige termijn af wilt maken.
Zodat er tijd is om een vervanger te zoeken, overdracht ed.

[TucanoItaly]

@Remcoder @hackerhater Ik ben niet de enige daar, hoor Bovendien is de klant in kwestie zich er van bewust dat ik een freelancer ben, daar heb ik voor gezorgd. Maar dat is nog iets anders dan hun neus er in wrijven.

[pirke]

Ondanks een opzegtermijn van 1 maand zou ik zeker 3 maanden van tevoren al aangeven weg te gaan, dat is volgens mij gewoon hoe je met elkaar omgaat. Het is een klein wereldje.

[Remcoder]

Ik zou er niet blij van worden als ik met iemand samengewerkt had die zonder inachtneming van een normale opzegtermijn vertrokken was.

Zou ik die persoon nog eens tegenkomen op een intake ergens zou ik de klant toch adviseren om niet met die persoon in zee te gaan.

[c-nan]

Ik heb het ongeveer 6 weken voor het aflopen van mijn contract aangegeven, ruim op tijd vind ik. Echter bij mijn vertrek was er nog steeds geen vervanger gevonden Wel waren we ~10 CV's en 3-4 gesprekken verder.

Ik zal echt niet 3 maanden van te voren aangeven dat ik weg ga, tenzij ik er 100% zeker van ben dat ze mij niet ineens eerder wegsturen omdat ze heel snel een vervanger hebben gevonden

Daarnaast ga ik het liefst pas weg zodra ik iets anders heb gevonden.

[hackerhater]

Ruim op tijd aangegeven, niet jouw probleem toch?
Dat is het risico van een externe, dat een gegeven moment weg gaat.

[ Voor 41% gewijzigd door hackerhater op 02-07-2021 14:50 ]

[Remcoder]

hackerhater schreef op vrijdag 2 juli 2021 @ 14:50:
Ruim op tijd aangegeven, niet jouw probleem toch?
Dat is het risico van een externe, dat een gegeven moment weg gaat.

Dat risico heb je ook met interne medewerkers. Als bedrijf moet je er maar gewoon rekening mee houden dat mensen op een gegeven moment iets anders gaan doen. Zolang een redelijke opzegtermijn in acht genomen wordt is daar ook niets mis mee.

Redelijk vind ik dan minstens 1 maand. En een klant gaat jou echt niet eerder wegsturen als je aangeeft dat je niet meer gaat verlengen. Meestal duurt het al minstens een maand om een vervanger te vinden, daarna moet die nog ingewerkt worden en ben je ook al gauw een maand verder. Dus je hebt sowieso nog 2 maanden dat je omzet uit die klant kan trekken. En als je dan ook nog elke keer voor 3 maanden verlengt heb je dus nog maar 1 maand te gaan, en dan is de kans ook groot dat een klant niet de moeite gaat nemen om jou eerder weg te sturen. En als ze het wel doen heb je gewoon eerder vakantie

Tenminste, dat is hoe ik het aan ga pakken straks, tussen 2 klanten even lekker 1-2 maanden relaxen, wat trainingen doen eventueel in die periode, en dan de volgende klus zoeken . Dus als ze mij straks eerder wegsturen omdat ik aangegeven heb weg te willen zal me dat niet veel uitmaken.

[MeZZiN]

een maand is meestal prima maar als je iets al klaar heb staan waarom niet eerder aangeven maar het kan ook zijn dat ze je gelijk kwijt willen.... het is een balanceer act.

[pirke]

Je gaat toch niet al iets zoeken als je nog bij een klant zit? Ik zit op de wat langere projecten, maar wil juist minimaal een maand vakantie voordat ik een nieuwe opdracht ga zoeken. Aan het einde van deze opdracht ga ik misschien wel een jaartje ff niks doen. Lijkt me heerlijk

[fry77]

pirke schreef op vrijdag 2 juli 2021 @ 19:37:
Je gaat toch niet al iets zoeken als je nog bij een klant zit? Ik zit op de wat langere projecten, maar wil juist minimaal een maand vakantie voordat ik een nieuwe opdracht ga zoeken. Aan het einde van deze opdracht ga ik misschien wel een jaartje ff niks doen. Lijkt me heerlijk

ik zoek als ik nog bij klant zit, of iig zodra ik een einddatum weet. Tegen de tijd dat intakes en screening achter de rug is heb ik mijn maand vrij wel gehad hoor. Ga ik voor einde contract weg dan laat ik dat wel een week of 6 van te voren weten. MAar dan nog zou het geen verrassing moeten zijn voor de opdrachtgever

[Deveon]

Mijn einddatum is inmiddels voor de twee keer verlengd. Ondertussen blijft ik de markt in gaten houden en als er iets voorbij komt voor een leuke tarief dan vind ik het mooi geweest.

[c-nan]

pirke schreef op vrijdag 2 juli 2021 @ 19:37:
Je gaat toch niet al iets zoeken als je nog bij een klant zit? Ik zit op de wat langere projecten, maar wil juist minimaal een maand vakantie voordat ik een nieuwe opdracht ga zoeken. Aan het einde van deze opdracht ga ik misschien wel een jaartje ff niks doen. Lijkt me heerlijk

Waarom niet? Je gaat bij een klant weg omdat je het geen leuk opdracht vind of toe bent aan iets nieuws, waarom pas zoeken nadat je er weg bent en niet tijdens?

Als je vakantie wilt dan neem je vakantie, imo staat dat los van een ander opdracht zoeken.

[Rutix]

c-nan schreef op vrijdag 2 juli 2021 @ 21:38:
[...]

Waarom niet? Je gaat bij een klant weg omdat je het geen leuk opdracht vind of toe bent aan iets nieuws, waarom pas zoeken nadat je er weg bent en niet tijdens?

Als je vakantie wilt dan neem je vakantie, imo staat dat los van een ander opdracht zoeken.

Eens, je kunt ook prima zoeken en afspreken dat de start datum een maand later is zodat je ook echt vakantie kan houden. Zoeken in mijn vakantie vind ik juist irritant omdat je dan intakes, telefoontjes enzo krijgt terwijl je eigenlijk wilt uitrusten of gewoon aan vakantie wilt denken .

[ Voor 14% gewijzigd door Rutix op 02-07-2021 22:28 ]

[jadjong]

Af en toe komt er hier iets voorbij over andere ondernemers, wie dat wel/niet is en de lage tarieven van bijvoorbeeld Deliveroo.

Het kan altijd erger.

'Pay to work'

[pirke]

@jadjong Dat is helaas vrij gebruikelijk in dat wereldje. Maar je hebt weinig keus: om je brevet geldig te houden moet je een minimum aantal uren vliegen. Daarnaast hebben *heel* veel vacatures de eis dat je minimaal 500 uur ervaring hebt op een specifiek bepaald type vliegtuig (bijv de 737) en 1500 uur totale ervaring.

Dus of je hebt heel veel geluk en je kan ervaring opbouwen terwijl je salaris krijgt, of je betaalt om je brevet geldig te houden en je koopt ervaringsuren. Zie het als een investering in de toekomst.

offtopic:
Ik heb in 2007 ook overwogen om dit te gaan doen. Toen heb ik zelfs nog aan de selectie meegedaan en die met glans doorstaan, maar werd in het eindgesprek toch medegedeeld dat ze me met klem adviseerde om iets anders te gaan doen vanwege een te hoge intelligentie Ze waren er van overtuigd dat ik me na een paar jaar enorm zou gaan vervelen en ze wilden me niet met 150k schuld opzadelen, en achteraf gezien denk ik dat ze gelijk hebben. Nu heb ik gewoon een privé vliegbrevet om als hobby te vliegen, dan blijft het leuk. En met de financiële crisis die zich vlak daarna ontwikkelde ben ik blij dat ik de keuzes heb gemaakt die ik toen gemaakt heb.

De barre situatie vd piloten is overigens waarom ik nooit met de bekende prijsvechters vlieg: de piloten zijn zeer onervaren, oververmoeid en hebben veel stress door hun financiën, veel lange dagen, druk vh management om zo min mogelijk brandstof mee te nemen (want "onnodig" extra gewicht), er wordt bespaard waar bespaard kan worden. Er zijn zelfs ranglijsten vanuit het management wie op een bepaalde route gemiddeld de meeste en minste brandstof verbruikt (een vriend van me heeft onder die condities gewerkt...). Nu moeten ze wettelijk nog een half uur reserve hebben als ze landen, dus regelmatig moeten ze op een druk vliegveld een "fuel emergency" melden als ze dreigen om met minder dan de minimale reserve te landen. Het vliegveld moet er op zo'n moment alles aan doen om het noodvliegtuig zo snel mogelijk te laten landen. Mocht er echter op dat moment een vervelende situatie op het vliegveld gebeuren (meestal onweer dat over waait, maar het voorgaande toestel kan ook een klapband krijgen of erger) dan moet de landingsbaan dicht en kan het noodtoestel dus niet landen. Dan heeft het minder dan 30 minuten om ergens anders te landen, dan mag er dus helemaal niks meer tegenzitten. Een go-around bij een verkeerde inschatting of onverwachte vlaag zijwind wordt dan heel spannend zullen we maar zeggen. Zie bijvoorbeeld https://www.bbc.com/news/world-europe-19267153 en https://www.eurocockpit.b...ir-defamation-allegations

Daarnaast vind ik het ook wel prettig om niet als vee behandeld te worden

[ Voor 40% gewijzigd door pirke op 03-07-2021 01:23 ]

[Aftansert]

Rutix schreef op vrijdag 2 juli 2021 @ 22:27:
[...]

Eens, je kunt ook prima zoeken en afspreken dat de start datum een maand later is zodat je ook echt vakantie kan houden.

Ligt wel heel erg aan de klus. Meeste dingen die ik wil aannemen geven aan liever gister dan vandaag te beginnen, en zullen zeker niet een maand gaan wachten. In de praktijk duurt het meestal alsnog een tijdje om alles in orde te krijgen, maar dat is wat te onvoorspelbaar als je eigenlijk op vakantie wilt.

[RonaldHeirbaut]

jadjong schreef op vrijdag 2 juli 2021 @ 23:48:
'Pay to work'

Niet helemaal 'pay to work' maar in 2008 hadden we ook de crisis en teveel ICT-ers. Er waren toen inhuurders die eenzijdig bepaalden dat ik hen 10% korting ging geven. of ik maar even akkoord wilde gaan... (guess what). Maar ook partijen als Cap Gemini, Ordina etc die een consultant voor 40 euro verhuurden en sterker, dan kreeg je er nog eentje gratis (om maar geen mensen op de bank te hebben). Dus ik moest met mijn 85 euro concureren tegen 2 man voor 40 euro.
Ik heb geleerd dat je niet moet meegaan in dat soort gedoe. Wil je me huren, betaal je fatsoenlijk. En anders maar niet, dan zoek je iemand anders. Daarnaast hebben we beiden getekend bij het kruisje, dus eenzijdig aanpassen is onmogelijk.

[sverzijl]

RonaldHeirbaut schreef op zaterdag 3 juli 2021 @ 08:10:
[...]

Niet helemaal 'pay to work' maar in 2008 hadden we ook de crisis en teveel ICT-ers. Er waren toen inhuurders die eenzijdig bepaalden dat ik hen 10% korting ging geven. of ik maar even akkoord wilde gaan... (guess what). Maar ook partijen als Cap Gemini, Ordina etc die een consultant voor 40 euro verhuurden en sterker, dan kreeg je er nog eentje gratis (om maar geen mensen op de bank te hebben). Dus ik moest met mijn 85 euro concureren tegen 2 man voor 40 euro.
Ik heb geleerd dat je niet moet meegaan in dat soort gedoe. Wil je me huren, betaal je fatsoenlijk. En anders maar niet, dan zoek je iemand anders. Daarnaast hebben we beiden getekend bij het kruisje, dus eenzijdig aanpassen is onmogelijk.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[jos707]

Ik heb de rol als fullstack developer dus bij een nieuwe opdracht heb je altijd een inwerkperiode, dit omdat ongeacht of je junior of senior bent je nooit alle tools en frameworks kent die vaak gebruikt worden bij het hele fullstack gebeuren. Ik zit sinds een maandje op een nieuwe opdracht en ook hier weer zijn er technisch wat dingen waar ik wat minder bekend mee ben, alsook de overdadige gebruikte meerlagige structuur opzet voelt niet meteen intuitief aan. Het is een klein team van jonge gemotiveerde seniors die agile/scrum werken en dagelijks ticketjes in snel tempo oppaken en afhandlen. Dit ritme is als nieuwkomer moeilijk bij te houden, zonder je halve vrije avond telkens te moeten opofferen.

Nu merk ik de laaste week bij de teamleads al enig gemorrel omdat ik niet snel genoeg storypoints oplever. Ik heb nooit eerder een opdracht aangenomen waar dit soort startup-kultuur heerst. En zou dit ook nooit gedaan hebben mocht dit eerder gebleken zijn tijdens de intake. Integendeel de intake was eigenlijk best relaxed en voelde gewoon goed aan.

Nu begin ik zelf wat te tweifelen hoeveel zin ik nog heb in deze opdracht. Hoewel vanuit technisch oogpunt alles uitermate interessant is en gewoon in lijn ligt van mijn ervaringen/skills weet ik niet of de sfeer in het team dit ook is. Dit gaat van het opbod van zoveel mogelijk 'presteren' to de opoffering van vrije tijd, bv sommige die hun middagmaal snel achter de latop binnenschrokken terwijl ze lustig verder code kloppen. Nuja de boel na een maand al afbreken lijkt mij wat te snel, dus ik geef het nog even en zie dan verder.
Zijn er mensen die al in soortgelijke situaties zijn terecht gekomen ?

[RichieB]

@sverzijl ik heb het 1x meegemaakt bij de ING. Ze wilden mijn tarief 20% omlaag hebben. Het signaal dat ik hieruit oppikte was “je bent dit tarief niet waard”. Nog voordat het onderhandelingsgesprek hierover plaats had gevonden was ik al in gesprek bij een andere opdrachtgever. Dus ik ben overgestapt en heb mijn tarief behouden. Waren ze bij de ING niet blij mee, maar ik heb er nooit spijt van gehad.

[Hydra]

TucanoItaly schreef op vrijdag 2 juli 2021 @ 13:11:
Ik ben zo onderhand wel toe aan een nieuwe klus, en hou nu een aantal sites uit de start post in de gaten. Ik dacht er over om LinkedIn te gebruiken, maar weet niet zo goed hoe dat aan te pakken. Gewoon posten "ik ben beschikbaar voor een klus" gaat de huidige klant zien, plus ik wil bij voorkeur geen recruiter er tussen.

Heeft iemand hints wat LinkedIn betreft, of tips voor zoeken naar een nieuwe iOS (mobile dev) klus?

Ik heb mezelf destijds op beschikbaar gezet en werd toen door een hoop recruiters benaderd, zonder uberhaupt op LinkedIn te posten. Wel aardig wat britten helaas (meestal tijdsverspilling). Eerst rondgevraagd in m'n directe persoonlijke netwerk maar daar kwam niks uit naar vorigen.

[Hydra]

jos707 schreef op zaterdag 3 juli 2021 @ 13:32:
Nu merk ik de laaste week bij de teamleads al enig gemorrel omdat ik niet snel genoeg storypoints oplever.

Maar hoe steek je dan daadwerkelijk af t.o.v. de huidige developers? Het is lastig om hier een reactie op te geven. Vragen ze te veel, of is het eigenlijk gewoon terecht? Voor een ZZPer betaal je t.o.v. een interne gewoon wel significant meer en meestal zijn de verwachtingen dan relatief hoog. Ik heb zelf ook wel een paar keer meegemaakt dat we afscheid van een ZZPer hebben genomen omdat deze zich voordeed als 'senior' maar ondertussen wel enorm aan de hand genomen moest worden.

Ik zeg niet dat dit hier het geval is, maar een maand moet m.i. wel genoeg tijd zijn om de tooling e.d. door te krijgen. Natuurlijk heeft een groot bestaand systeem hoeken en gaten waar niet iedereen van weet, maar als ik na een maand nog aan een ZZPer uit moet leggen hoe onze Maven builds fungeren, tja.

Nogmaals; ik ken je niet en dit is dus expliciet geen oordeel over jouw situatie!

[Hydra]

pirke schreef op vrijdag 2 juli 2021 @ 19:37:
Je gaat toch niet al iets zoeken als je nog bij een klant zit? Ik zit op de wat langere projecten, maar wil juist minimaal een maand vakantie voordat ik een nieuwe opdracht ga zoeken. Aan het einde van deze opdracht ga ik misschien wel een jaartje ff niks doen. Lijkt me heerlijk

Ik snap wel dat je het wil/doet hoor. Ik heb tijdens m'n vorige opdracht naar een nieuwe gezocht (liep per 30 Nov af dus per 1 Nov gaan zoeken) vooral omdat ik niet echt plannen had iets te gaan doen. Dan zit ik heel Dec thuis uit m'n neus te eten (dit was 2020 natuurlijk). Daarbij wisten we dat we dit jaar gingen verhuizen en dus ga ik als ik dan toch niks te doen heb liever geld verdienen

Komt bij dat ik meestal ook wel zin heb in een nieuwe uitdaging, dus dan heb ik liever dat ik dan meteen aan de slag kan. Voor m'n gevoel heb ik dan ook al afscheid genomen van het 'oude'.

[jos707]

Hydra schreef op zaterdag 3 juli 2021 @ 13:46:
[...]


Maar hoe steek je dan daadwerkelijk af t.o.v. de huidige developers? Het is lastig om hier een reactie op te geven. Vragen ze te veel, of is het eigenlijk gewoon terecht? Voor een ZZPer betaal je t.o.v. een interne gewoon wel significant meer en meestal zijn de verwachtingen dan relatief hoog. Ik heb zelf ook wel een paar keer meegemaakt dat we afscheid van een ZZPer hebben genomen omdat deze zich voordeed als 'senior' maar ondertussen wel enorm aan de hand genomen moest worden.

Ik zeg niet dat dit hier het geval is, maar een maand moet m.i. wel genoeg tijd zijn om de tooling e.d. door te krijgen. Natuurlijk heeft een groot bestaand systeem hoeken en gaten waar niet iedereen van weet, maar als ik na een maand nog aan een ZZPer uit moet leggen hoe onze Maven builds fungeren, tja.

Nogmaals; ik ken je niet en dit is dus expliciet geen oordeel over jouw situatie!

Inmiddels is er geen probleem om op volle snelheid mee te draaien, klopt er zijn nog wat dingen waar ik niet de expertise heb als iemand die al wat langer in het team zit maar dit belemmert grotendeels het werk niet. Wat mijn vooral tegenzit is de opgejaagde sfeer en het hoge 'nerd' gehalte waar iedereen blijkt te leven in functie van zijn werk. Ik mis gewoon het gezellige in de groep, waar je soms ook gewoon even over koetjes&kalfjes kan hebben zonder dat elk gesprek meteen moet gaan over techniciteiten. Als je vrijdagnamiddag zegt dat je een uurtje vroeger stopt klinkt al snel wat vreemd.

[Hydra]

jos707 schreef op zaterdag 3 juli 2021 @ 14:06:
Inmiddels is er geen probleem om op volle snelheid mee te draaien, klopt er zijn nog wat dingen waar ik niet de expertise heb als iemand die al wat langer in het team zit maar dit belemmert grotendeels het werk niet. Wat mijn vooral tegenzit is de opgejaagde sfeer en het hoge 'nerd' gehalte waar iedereen blijkt te leven in functie van zijn werk. Ik mis gewoon het gezellige in de groep, waar je soms ook gewoon even over koetjes&kalfjes kan hebben zonder dat elk gesprek meteen moet gaan over techniciteiten. Als je vrijdagnamiddag zegt dat je een uurtje vroeger stopt klinkt al snel wat vreemd.

Ik vind zelf teamcultuur ook erg belangrijk. Als er geen klik is, dan is die er niet. Maar dat is echt iets wat je voor jezelf uit moet maken.

[jos707]

pirke schreef op vrijdag 2 juli 2021 @ 19:37:
Je gaat toch niet al iets zoeken als je nog bij een klant zit? Ik zit op de wat langere projecten, maar wil juist minimaal een maand vakantie voordat ik een nieuwe opdracht ga zoeken. Aan het einde van deze opdracht ga ik misschien wel een jaartje ff niks doen. Lijkt me heerlijk

Ik vraag mij af hoe je volgende opdrachtgever ertegenaan kijkt dat je een jaartje niks hebt gedaan.Ik weet wat je vakgebied is maar als je als developer een jaartje niets doet loop je eigenlijk beetje achter.

[ANdrode]

jos707 schreef op zaterdag 3 juli 2021 @ 14:42:
[...]

Ik vraag mij af hoe je volgende opdrachtgever ertegenaan kijkt dat je een jaartje niks hebt gedaan.Ik weet wat je vakgebied is maar als je als developer een jaartje niets doet loop je eigenlijk beetje achter.

Ik denk dat je in "javaan" niet zoveel mist in een jaar

offtopic:
Sorry: Geen idee waarin je specialiseert - maar er zijn subsectoren waarin een jaar niet zoveel doet voor wat betreft achter lopen.

Hydra schreef op zaterdag 3 juli 2021 @ 13:46:
[...]
Maar hoe steek je dan daadwerkelijk af t.o.v. de huidige developers? Het is lastig om hier een reactie op te geven. Vragen ze te veel, of is het eigenlijk gewoon terecht? Voor een ZZPer betaal je t.o.v. een interne gewoon wel significant meer en meestal zijn de verwachtingen dan relatief hoog. Ik heb zelf ook wel een paar keer meegemaakt dat we afscheid van een ZZPer hebben genomen omdat deze zich voordeed als 'senior' maar ondertussen wel enorm aan de hand genomen moest worden.

Het kan ook gewoon zo zijn dat ze écht goede developers aan hebben weten te trekken. Dan verschuift hun referentiekader ook. Soms hebben startups dat geluk.

[pirke]

jos707 schreef op zaterdag 3 juli 2021 @ 14:42:
[...]

Ik vraag mij af hoe je volgende opdrachtgever ertegenaan kijkt dat je een jaartje niks hebt gedaan.Ik weet wat je vakgebied is maar als je als developer een jaartje niets doet loop je eigenlijk beetje achter.

Hoezo loop je dan achter? Als ik kijk hoe er nu ontwikkeld wordt en 15 jaar geleden, dan is dat gewoon hetzelfde. Ja de syntax is ietsiepietsie verandert, maar conceptueel is het allemaal hetzelfde. Ik doe geen web, misschien scheelt dat.

Verder is het juist een pluspunt als mensen goed uitgerust zijn en lekker in hun vel zitten.

Het helpt dat ik het inkomen ook niet echt meer nodig heb, dus het zal allemaal wel los lopen

[Rutix]

Aftansert schreef op zaterdag 3 juli 2021 @ 01:41:
[...]

Ligt wel heel erg aan de klus. Meeste dingen die ik wil aannemen geven aan liever gister dan vandaag te beginnen, en zullen zeker niet een maand gaan wachten. In de praktijk duurt het meestal alsnog een tijdje om alles in orde te krijgen, maar dat is wat te onvoorspelbaar als je eigenlijk op vakantie wilt.

Als je het wilt dan zijn ze echt wel te vinden . Ze willen natuurlijk wel zsm maar je kunt er meestal wel over hebben met de eindklant (een recruiter doet altijd moeilijk).

jos707 schreef op zaterdag 3 juli 2021 @ 14:42:
[...]

Ik vraag mij af hoe je volgende opdrachtgever ertegenaan kijkt dat je een jaartje niks hebt gedaan.Ik weet wat je vakgebied is maar als je als developer een jaartje niets doet loop je eigenlijk beetje achter.

Een jaartje valt echt wel mee hoor. De software wereld gaat snel maar niet zo snel. Bijvoorbeeld ik doe vaak .NET klussen en als je daar een jaartje uit bent ben je niet opeens useless. Een goede developer pakt de nieuwe dingen ook weer snel op en ik vind meestal ook wel ondernemend als je ervoor kiest om even een jaartje te focussen op jezelf of andere dingen. De opdrachtgevers in mijn netwerk doen echt totaal niet moeilijk als je er een jaartje uit bent geweest, sterker nog ik kan aardig wat ZZP-ers die een jaar hebben gereist en die totaal geen problemen hadden om een opdracht te vinden.

[jos707]

Rutix schreef op zaterdag 3 juli 2021 @ 16:55:

Een jaartje valt echt wel mee hoor. De software wereld gaat snel maar niet zo snel. Bijvoorbeeld ik doe vaak .NET klussen en als je daar een jaartje uit bent ben je niet opeens useless. Een goede developer pakt de nieuwe dingen ook weer snel op en ik vind meestal ook wel ondernemend als je ervoor kiest om even een jaartje te focussen op jezelf of andere dingen. De opdrachtgevers in mijn netwerk doen echt totaal niet moeilijk als je er een jaartje uit bent geweest, sterker nog ik kan aardig wat ZZP-ers die een jaar hebben gereist en die totaal geen problemen hadden om een opdracht te vinden.

Hangt ook een beetje af wat de verwachtingen zijn van de klant. Mijn laatste opdrachtgever verwacht dat je snel mee bent met recente ontwikkelingen op web/backend tooling en frameworks. Ik zeg niet dat je na een jaar useless bent maar vermoed dat je toch wat meer inwerktijd ga nodig hebben om terug up to speed te zijn. Nu als de opdracht van langere duur is en dit toelaat prima natuurlijk, maar bij een klus van enkele maanden waar een strakke deadline opstaat heb je die vrijheid minder. Een jaartje niksen klint leuk maar dan ook een jaar zonder inkomen is wat minder aanlokkelijk dus ik ga het probleem vooralsnog niet hebben

[Crazy D]

jos707 schreef op zaterdag 3 juli 2021 @ 13:32:
Nu merk ik de laaste week bij de teamleads al enig gemorrel omdat ik niet snel genoeg storypoints oplever. Ik heb nooit eerder een opdracht aangenomen waar dit soort startup-kultuur heerst. En zou dit ook nooit gedaan hebben mocht dit eerder gebleken zijn tijdens de intake. Integendeel de intake was eigenlijk best relaxed en voelde gewoon goed aan.

Ja, maar vanaf de andere kant zeg maar. In 'mijn wereld' hoef je niet eerst 2 maanden in te werken, als je de tooling kent moet je na een paar dagen echt wel kleine dingetjes kunnen oppakken. Zeker, dat kost extra tijd dan dat een ervaren teamlid dat doet, dat mag ook best 6 keer zo lang duren. Maar pro-actieve houding, niet dagenlang rondzwemmen maar na een uurtje zoeken vragen "joh hoe werkt dit precies" (en met dit bedoel ik niet de tools maar de oplossing waar je aan werkt) is wel een vereiste. Als je heel lang rondzoekt en kijkt is de kans ook groot dat je hele delen mist en dat je fix/oplossing wellicht maar 1/4 van de echte oplossing is.

Enige wat je denk ik kunt doen is in gesprek gaan. Waarom kosten bepaalde dingen jou nog meer tijd.

[Sjors31415]

Om mijn inkomsten te diversificiëren heb ik een oefentoets gemaakt voor Apache Spark en verkoop ik op Udemy, ben benieuwd of het een succes wordt. Zijn er andere mensen hier die ervaring hebben met het online verkopen van trainingen op die platforms?

PS Mocht iemand hier geïnteresseerd zijn kan ik een gratis code delen voor die oefentoets, stuur me een PM.

[Yucon]

Sjors31415 schreef op zondag 4 juli 2021 @ 23:23:
Om mijn inkomsten te diversificiëren heb ik een oefentoets gemaakt voor Apache Spark en verkoop ik op Udemy, ben benieuwd of het een succes wordt. Zijn er andere mensen hier die ervaring hebben met het online verkopen van trainingen op die platforms?

PS Mocht iemand hier geïnteresseerd zijn kan ik een gratis code delen voor die oefentoets, stuur me een PM.

M'n vrouw is nu met zoiets bezig (niet tech). Al weet ik eerlijk gezegd niet precies hoe dat gehost is, maar de rode draad lijkt te zijn dat je je cursussen alleen succesvol kunt verkopen met een flinke fanbase. Anders wordt het gewoon te lastig om nog tussen de rest van het aanbod op te vallen.

En dat kost weer heel wat werk in de zin van het bijhouden van social media.

[ Voor 4% gewijzigd door Yucon op 05-07-2021 07:25 ]

[RonaldHeirbaut]

Sjors31415 schreef op zondag 4 juli 2021 @ 23:23:
Om mijn inkomsten te diversificiëren heb ik een oefentoets gemaakt voor Apache Spark en verkoop ik op Udemy, ben benieuwd of het een succes wordt. Zijn er andere mensen hier die ervaring hebben met het online verkopen van trainingen op die platforms?

PS Mocht iemand hier geïnteresseerd zijn kan ik een gratis code delen voor die oefentoets, stuur me een PM.

Ik ken iemand die heel wat Nederlands ICT boeken heeft geschreven mbt Linux etc. Intussen is hij geswitcht naar online trainingen. Maar ook dat kost veel tijd en energie, maar levert ook meer op. Terecht gesteld, je moet al wel een naam hebben of een unique sellingpoint. Anders wordt het lastig.
Op Udemy zal je mij NOOIT zien. Ik heb er al (te) vaak een cursus gezien die letterlijk gestolen is van een ander platform. Werkelijk schandalig dat Udemy dat toestaat. Google het maar eens op.

Ooit, voor de Covid, gaf ik nog met enige regelmaat trainingen RHCSA/LPI maar ik ben er mee gestopt. Het kost immens veel voorbereidingstijd en levert onder aan de streep te weinig op als je het erbij doet. Ik moest kiezen, fulltime trainer, of blijven doen wat je doet.