:strip_exif()/u/62716/avatar.gif?f=community){kind=avatar}
Maakt mij niet zoveel uit, we hebben maar paar servers en het is maar 1x per maand, maarja, blijkbaar heeft Windows 2016 ook een "Tablet Mode"...:
[...]
Ah. Updates met het handje is ook wel enigszins omslachtig imo, maar ieder z'n ding
:strip_icc():strip_exif()/u/284419/Mexican%2520Wolf%2520Klein.jpg?f=community)
:strip_icc():strip_exif()/u/87691/avatar_alex.jpg?f=community){kind=avatar}
/u/313216/crop679f937b7f4c1_cropped.png?f=community)
Ik los dit op door binnen een project (team project in TFS) event notification te configureren. Alle work items die assigned zijn bij mij en gewijzigd worden door een andere persoon (dan mezelf) zorgen voor een e-mail. Op die manier weet je wanneer een snoodaard iets wijzigt.
:strip_exif()/u/27216/bosmonster_dropdown.gif?f=community)
Jij zou er niet van over de zeik moeten gaan, maar je PO!:
[...]
Klopt, daarom vind ik het ook heel erg irritant dat het gebeurt is.
Toen ik een keer op een nieuw project terechtkwam stelde de PM zo'n regel in voor mij, ondanks mijn verzoek om dat niet te doen. Toen de eerste mailtjes binnen kwamen heb ik een berichtregel in Outlook gemaakt die elke mail van TFS automatisch naar hem doorstuurde.:
[...]
Ik los dit op door binnen een project (team project in TFS) event notification te configureren. Alle work items die assigned zijn bij mij en gewijzigd worden door een andere persoon (dan mezelf) zorgen voor een e-mail. Op die manier weet je wanneer een snoodaard iets wijzigt.
De regel werd heel snel weer weggehaald
We are shaping the future
:strip_exif()/u/199617/chidori.gif?f=community)
Volgens mij was Vista juist gebaseerd op Server 2003. Daarvoor liepen de server edities gewoon hand in hand met de desktop versies van Windows NT.
Heb ik vanochtend ingesteld, bedankt voor de tip:
[...]
Ik los dit op door binnen een project (team project in TFS) event notification te configureren. Alle work items die assigned zijn bij mij en gewijzigd worden door een andere persoon (dan mezelf) zorgen voor een e-mail. Op die manier weet je wanneer een snoodaard iets wijzigt.
Als we die hebben ben ik het, mits ik de bijbehorende pet kan vinden. Ik ben de enige ontwikkelaar, de voornaamste reden dat we SCRUM zijn gaan gebruiken is omdat ik gek werd van alle nieuwe wijzigingen die vanuit de organisatie nu, gisteren of de dag ervoor geïmplementeerd moesten zijn terwijl ik midden in iets anders zat.
[ Voor 59% gewijzigd door Neko Koneko op 16-06-2017 09:38 ]
End-users are clingy complaining dipshits who will never ever be grateful for any concession you make. The moment you shut out their shrill, tremulous voices, the happier you will be for it.
Oh, ik vind het net handig dat ik een notification krijg.:
[...]
Toen ik een keer op een nieuw project terechtkwam stelde de PM zo'n regel in voor mij, ondanks mijn verzoek om dat niet te doen. Toen de eerste mailtjes binnen kwamen heb ik een berichtregel in Outlook gemaakt die elke mail van TFS automatisch naar hem doorstuurde.
De regel werd heel snel weer weggehaald
/u/12668/hydra.png?f=community)
Jullie doen niet aan Scrum maar aan ScrumBut:
Als we die hebben ben ik het, mits ik de bijbehorende pet kan vinden. Ik ben de enige ontwikkelaar, de voornaamste reden dat we SCRUM zijn gaan gebruiken is omdat ik gek werd van alle nieuwe wijzigingen die vanuit de organisatie nu, gisteren of de dag ervoor geïmplementeerd moesten zijn terwijl ik midden in iets anders zat.
https://niels.nu
Waar ik nu zit gebruiken we JIRA, en dan meer specifiek de online-versie. In m'n settings kan ik nergens een optie vinden om e-mail notificaties uit te zetten en ook de PM hier heeft geen idee hoe dat te doen.:
[...]
Oh, ik vind het net handig dat ik een notification krijg.
Dus...
We are shaping the future
:strip_icc():strip_exif()/u/269508/crop55c9d5fae106a_cropped.jpeg?f=community)
Klopt, daar heb ik ook al eens naar zitten zoeken... Maar welke notificaties naar wie gestuurd moeten worden wordt ernstig globaal ingesteld 
Gevolg? Hele team laat JIRA notificaties wegfilteren naar een submap van de Inbox.
Gevolg? Hele team laat JIRA notificaties wegfilteren naar een submap van de Inbox.
/u/48320/kenshin60.png?f=community)
/u/81985/crop566b00b43645a.png?f=community)
:strip_icc():strip_exif()/u/383603/Untitled.jpg?f=community)
Een keyboard op je kop! De horror!!!:
En wat verdien je als je beide gebruikt?
Always looking for developers wanting to work with Erlang.
/u/373849/cowava2.png?f=community)
Ja, oy, ehm, m'n toetsenbord rechtop is een beetje onhandig!:
[...]
Een keyboard op je kop! De horror!!!
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
/u/56000/neuken.png?f=community)
Onderzoek gelezen? Die zeggen dat je het minst verdiend.:
En wat verdien je als je beide gebruikt?
/me volgende keer beter op de indentatie letten, dat kost me anders geld
let the past be the past.
:strip_exif()/u/316566/crop570109b769a18_cropped.gif?f=community)
Same here. Jira is fijn hoor, maar dat onding managen, brrrr.:
Klopt, daar heb ik ook al eens naar zitten zoeken... Maar welke notificaties naar wie gestuurd moeten worden wordt ernstig globaal ingesteld
Gevolg? Hele team laat JIRA notificaties wegfilteren naar een submap van de Inbox.
* Mercatres zit aan poging #3 om een betere structuur in de groups en projecten te creeëren. (Gelukkig krijg ik daar tijd voor van m'n PO
)
:strip_icc():strip_exif()/u/315253/boy-tweakers.jpg?f=community)
Ik vraag me af hoeveel geld de mensen gemiddeld verdienen die niet geantwoord hebben op deze survey omdat ze wel wat beters te doen hadden
Nothing to see here!
/u/105842/Homer_60x60.png?f=community)
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
Ah, je wil graag nog minder verdienen dus
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
:strip_exif()/u/39092/wolkje-avatar3.gif?f=community){kind=avatar}
De grote vraag is uiteraard hoe het met causatie en correlatie zit. 
Stel je hebt een tab-ontwikkelaar en deze gaat switchen naar volledig spatiegebruik; gaat die ontwikkelaar dan ook meer verdienen? Of moet je een bepaald type ontwikkelaar zijn - die sowieso al spaties gebruikt - en verdient dat type ontwikkelaar gewoon sowieso meer?
Stel je hebt een tab-ontwikkelaar en deze gaat switchen naar volledig spatiegebruik; gaat die ontwikkelaar dan ook meer verdienen? Of moet je een bepaald type ontwikkelaar zijn - die sowieso al spaties gebruikt - en verdient dat type ontwikkelaar gewoon sowieso meer?
Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana
Tja, of je hebt je zoals ik weinig te kiezen en schikt je gewoon naar wat de rest van de codebase al heeft:
Stel je hebt een tab-ontwikkelaar en deze gaat switchen naar volledig spatiegebruik; gaat die ontwikkelaar dan ook meer verdienen? Of moet je een bepaald type ontwikkelaar zijn - die sowieso al spaties gebruikt - en verdient dat type ontwikkelaar gewoon sowieso meer?
Vooralsnog is mijn uurtarief niet afhankelijk van tabs of spaces voor zover ik kan zien
[ Voor 8% gewijzigd door Hydra op 19-06-2017 09:42 ]
https://niels.nu
True dat zal vaak zo zijn:
[...]
Tja, of je hebt je zoals ik weinig te kiezen en schikt je gewoon naar wat de rest van de codebase al heeft
Bij ons was het van origine ook een beetje van beide maar nieuwere code wordt eigenlijk alleen van nog spaties voorzien en oude wordt zo mogelijk omgezet. Het werd een beetje gedoe om de code er in alle tooling steeds netjes uit te laten zien, dan moet je op een gegeven moment toch kiezen.
Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana
Inderdaad. En je wil ook graag dat alle devs hun tooling hetzelfde ingesteld hebben zodat je niet iedere keer met grote GIT diffs zit.:
True dat zal vaak zo zijn
https://niels.nu
:strip_exif()/u/80759/monstermania_small.gif?f=community)
:strip_icc():strip_exif()/u/148671/skyaero_small_tweakers.jpg?f=community)
Daarnaast: mogelijke bias in de onderzoeksgroep.:
De grote vraag is uiteraard hoe het met causatie en correlatie zit.
Verder: hoe zit het met de onzekerheid/standaard deviatie. Er wordt nu zelfs geconcludeerd dat als je 'both' doet, je minder verdient dan alleen 'tabs', maar die twee curves liggen zodanig dicht bij elkaar dat het nog maar de vraag is of je zo'n conclusie mag trekken.
Als laatste is er ook nog de rol die een IDE in het verhaal speelt. Als de 'tab' toets gebruikt en de IDE maakt er 'spaces' van, hoe telt het dan mee?
There are lies, damn lies and statistcs
Ik mag echt hopen dat dat gewoon telt als spaties anders slaat het onderzoek daadwerkelijk nergens op. Ik ben een spatie-ontwikkelaar maar ik ben echt niet zo gek dat ik daadwerkelijk alles met de spatiebalk loop in te vullen
Never attribute to malice that which can be adequately explained by stupidity. - Robert J. Hanlon
60% of the time, it works all the time. - Brian Fantana
/u/411828/crop576907a75c281.png?f=community)
Ik mag hopen dat niemand 2/4/8 keer op die spatiebalk ramt voor iedere regel:
[...]
Ik mag echt hopen dat dat gewoon telt als spaties anders slaat het onderzoek daadwerkelijk nergens op. Ik ben een spatie-ontwikkelaar maar ik ben echt niet zo gek dat ik daadwerkelijk alles met de spatiebalk loop in te vullen
Hier een spatieontwikkelaar die op de tab drukt, waarna er 4 spaties verschijnen
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Mijn IDE doet al dat soort dingen automagisch, en als het niet goed is fixt Ctrl-K Ctrl-D het vanzelf
We are shaping the future
Ik herken ze meteen (zo uniek zijn ze...), die verschrikkelijke Visual Studio shortcuts:
[...]
Mijn IDE doet al dat soort dingen automagisch, en als het niet goed is fixt Ctrl-K Ctrl-D het vanzelf
Als ik ooit iets in Visual Studio moet doen gaat meteen ReSharper erop en switch ik naar IntelliJ shortcuts. Jetbrains FTW
Wie verzint dat nou: Ctrl-K, Ctrl-C ipv Ctrl-/
[ Voor 6% gewijzigd door P1nGu1n op 19-06-2017 10:53 ]
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
:strip_icc():strip_exif()/u/73625/Tetris_failure_ava_forum.jpg?f=community)
Het staat je vrij om ze gewoon via het settings scherm aan te passen hoor:
[...]
Ik herken ze meteen (zo uniek zijn ze...), die verschrikkelijke Visual Studio shortcuts
Als ik ooit iets in Visual Studio moet doen gaat meteen ReSharper erop en switch ik naar IntelliJ shortcuts. Jetbrains FTW
Wie verzint dat nou: CTRL-K, CTRL-C ipv CTRL-/
scheelt je weer een resharper licentie (although ik resharper om een heleboel andere redenen gewoon van harte aanbeveel hoor )Overigens moet ik zeggen dat ik inmiddels heel erg gecharmeerd van VS Code ben
klein, snel en via het add-in model prima naar smaak aan te passen. Wij doen zelfs een compleet project in VS Code omdat het alle middelen bied die wij voor dat project nodig hebben (git integratie, TypeScript support, Web debugging integratie, refactoring, etc). Tot nu toe bevalt het prima en hebben we op geen moment hoeven terug te grijpen op Visual Studio.
[ Voor 26% gewijzigd door Laurens-R op 19-06-2017 10:58 ]
Tsja, kwestie van smaak en muscle memory. Na een paar keer weet je niet beter:
[...]
Wie verzint dat nou: Ctrl-K, Ctrl-C ipv Ctrl-/
We are shaping the future
Uiteraard, maar ReShaper wil ik sowieso gebruiken en scheelt weer alle shortcuts handmatig aanpassen:
[...]
Het staat je vrij om ze gewoon via het settings scherm aan te passen hoor
Ik heb VS overigens al tijden niet meer aangeraakt, mijn tijd breng ik door in Android Studio, IntelliJ of soms WebStorm. JetBrains IDEs
Ik heb dergelijke editors (Electron based: VS Code, Atom) ook wel eens geprobeerd, maar ik vond het toch allemaal te traag werken, zeker bij grote bestanden. Je voelt IMO dat het web-based is en niet native, dus ik was snel weer terug bij Sublime Text, net zoveel plugins maar voelt vlugger aan voor mij.Overigens moet ik zeggen dat ik inmiddels heel erg gecharmeerd van VS Code ben
Hoe ervaar jij dit?
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Python werkt ook met tabs.:
[...]
PHP slikt alles. Eerder Python waarschijnlijk
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
/u/243953/crop56f55a7bcf291.png?f=community)
PEP8, wat het meest gebruikt word, prefereert toch echt spaties in zo verre dat je er moeite voor moet doen om met tabs te werken:
[...]
Python werkt ook met tabs.
Mag alleen niet meer mixen met python3, een income upgrade feature pur sang:
[...]
Python werkt ook met tabs.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Stukje oude code wat ik tegenkom op het werk:
Ter verdediging: hij gebruikte hiervoor geen IDE en drukte soms op tabs, maar ook wel eens op spaties. En als je whitespace echt hidden is valt het niet echt op. Totdat anderen er ook aan moeten werken.
[ Voor 18% gewijzigd door Marcj op 19-06-2017 12:32 ]
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Ik moet denk ik maar overstappen op spaties, kan ik daarna met mijn baas gaan praten over mijn salaris...
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/288728/dingetje.png?f=community)
Hij was degene die met het product gestart is (zonder echte software ontwikkeling ervaring, maar handig in PHP). Gelukkig leert hij snel en wil hij tegenwoordig ook niet meer zonder IDE
Nu is het alleen mijn taak om de code ook weer opgeschoond te krijgen 
Meh. Ik ben geen schoonmaker. You break it you fix it. Anders leren ze 't nooit.:
Hij was degene die met het product gestart is (zonder echte software ontwikkeling ervaring, maar handig in PHP). Gelukkig leert hij snel en wil hij tegenwoordig ook niet meer zonder IDE
https://niels.nu
Helaas is het niet zo simpel, er staat al erg veel code live en functioneel doet alles het. En we krijgen van de baas maar beperkt de ruimte om code op te schonen, want er moet ook aan nieuwe functionaliteit gewerkt worden.
Wat zou ik graag een paar weken de tijd hebben om eens een grote refactorslag te maken in de code...
Het draait bij managers om getalletjes: de ROI (Return on Investment):
[...]
Helaas is het niet zo simpel, er staat al erg veel code live en functioneel doet alles het. En we krijgen van de baas maar beperkt de ruimte om code op te schonen, want er moet ook aan nieuwe functionaliteit gewerkt worden.
Wat zou ik graag een paar weken de tijd hebben om eens een grote refactorslag te maken in de code...
Als die positief is dan betaald het zich terug: na refactor beter onderhoudbaar en uitbreidbaar bijvoorbeeld. Dan kan je manager wel ineens geïnteresseerd zijn
[ Voor 4% gewijzigd door P1nGu1n op 19-06-2017 15:05 ]
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Dat snapt hij ook wel, maar we zoeken de middenweg zodat we niet helemaal tot een stilstand komen. Helaas duurt het al een jaar zo... nogal veel code gemaakt...:
[...]
Het draait bij managers om getalletjes: de ROI (Return on Investment)
Als die positief is dan betaald het zich terug: na refactor beter onderhoudbaar en uitbreidbaar bijvoorbeeld. Dan kan je manager wel ineens geïnteresseerd zijn
:strip_icc():strip_exif()/u/734655/crop6390c3acd41c6_cropped.jpg?f=community)
Gewoon code opschonen terwijl je bezig bent. Een grote refactorslag werkt alleen als je hele duidelijke kaders hebt. Zelfs voor privé projecten hou ik die regel aan.:
[...]
Helaas is het niet zo simpel, er staat al erg veel code live en functioneel doet alles het. En we krijgen van de baas maar beperkt de ruimte om code op te schonen, want er moet ook aan nieuwe functionaliteit gewerkt worden.
Wat zou ik graag een paar weken de tijd hebben om eens een grote refactorslag te maken in de code...
Doe ik dat niet dan zie ik snel dat de refactorslag een project op zichzelf wordt.
Ik heb het me mijn baas ook vaak over onderhoudskosten. "Als we nu toch A moeten doen dan kunnen we ook B aanpassen. Mochten we in de toekomst dan C doen dan zijn de onderhoudskosten een stuk lager. Dat kost nu 20 manuur extra maar bespaart ons in de toekomst elke keer dat we hier aankomen 8 manuur als gevolg van een bug, onderzoek of aanpassing. Met die 20 manuur extra kan ik dat terug brengen na 1 manuur."
Dat maakt de discussie concreet. Hij kan dan antwoorden dat C nooit zal gebeuren.
Of hij kan besluiten dat hij de voorkeur heeft voor de technische schuld zodat er nu technische winst gehaald kan worden.
Bovendien als je in de toekomst tegen die schuld aanloopt en hij gaat klagen dat het zo lang duurt kan je hem hier naar verwijzen.
Zomaar tegen je baas vertellen dat de code kut is kan hij ook niks mee. Zorg voor een oplossing en zorg dat die oplossing concreet is zodat hij weet want de omzet en kosten zijn.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
/u/3813/100_8985_ICON2.JPG?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Dit is ook exact de discussie die we regelmatig voeren. Wat we hier nu proberen is elke keer dat we iets nieuws moeten maken, dat we alleen de gerelateerde code direct meepakken in het verbeteren. Zo heb je toch een relatief beperkte scope en zit je aan code die je toch weer uitgebreid moet testen en test je de refactor ook direct.
Het enige is dat er behoorlijk wat work-arounds zijn ontstaan om nieuwe en oude code aan elkaar te kleien, wat nog wel eens frustreert. En ik zou graag eens wat van die work-arounds beter oplossen en daarbij een paar oude stukken code aanpakken waar we functioneel gezien niet aan hoeven te zitten nu.
Maar goed, we hebben hier in ieder geval goede gesprekken over, geen klachten hoor!
Om nog een voorbeeldje te geven van een hele vieze work-around:
PHP:
1
2
3
4
5
6
7
| $_POST[ 'domain' ] = API::data( 'domain', $user[ 'userLogonDomain' ], $u ); $_POST[ 'useremail' ] = API::data( 'email', $user[ 'userEmail' ], $u ); $_POST[ 'first' ] = API::data( 'firstName', $user[ 'userFirstName' ], $u ); $_POST[ 'last' ] = API::data( 'lastName', $user[ 'userLastName' ], $u ); $_POST[ 'notes' ] = API::data( 'notes', $user[ 'userNotes' ], $u ); // En nog wat meer van dit soort spullen $ownerModel->saveOwner(); |
Want tja, dat oude owner model zat gewoon post variabelen uit te lezen en de scope werd te groot om die gelijk ook te herschrijven.
Tja. Je kunt altijd op zoek naar een andere baas. Uiteindelijk is het jouw schuld als de code kut is. Dat voorkom ik liever dan dat ik midden in de nacht wakker gebeld wordt.
Natuurlijk chargeer ik een beetje maar in principe doe ik geen projecten waar ik die ruimte niet krijg.
Precies wat ik dus bedoel. Technical debt moet weggewerkt worden. Als ik daar dan nooit echt de mogelijkheid toe krijg moeten ze maar op zoek naar iemand die altijd netjes ja knikt op elke opdracht.Wat zou ik graag een paar weken de tijd hebben om eens een grote refactorslag te maken in de code...
Het is een beetje als een schrijver 90 euro per uur betalen maar hem dan niet de ruimte geven het begin van het verhaal om te bouwen indien nodig, maar dan wel verwachten dat 't een bestseller wordt. Ain't gonna happen.
https://niels.nu
Zoals ik het las was het geen kritiek, maar eerder een wens van onbeperkte capaciteit tot je beschikking krijgen. Ik vond het voorbeeld van @Marcj juist zeer sprekend van hoe het in de praktijk gaat: Een combinatie van idealen en pragmatisch denken.
Verder chargeer je wel heel erg
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Da's wat anders; dan ben je gewoon een prutser
Waar het me om gaat is dat naarmate software groeit je niet eindeloos kunt blijven voortbouwen op hetzelfde fundament. Op een gegeven moment zijn er vaak fundamentele zaken die niet lekker werken. Dan maar gewoon features blijven bouwen vertraagt je alleen maar op de lange termijn. Ik probeer dat soort grote refactorslagen (waar ik dan een week of meer mee bezig ben) te vertalen in de wins in de lange termijn. Zo heb ik een tijd geleden een stuk van onze data storage laag herschreven waardoor de service specifieke code voor een heel groot deel verwijderd kon worden. Dat levert ons met een team van zo'n 8 back-enders nog steeds dagelijks winst op. Hoe langer je dat uitstelt hoe meer tijd je aan het verspillen bent.
Natuurlijk zijn prio's belangrijk. Helemaal logisch dat er soms gewoon een feature af moet. Daar heb ik geen enkel probleem mee. Zolang de PO maar begrijpt dat er wel een lange-termijn visie moet zijn waarbij dit soort dingen af en toe moeten gebeuren. Als ik in een team werk waarbij het alleen maar features plakken en brandjes blussen is dan ga ik liever op zoek naar een ander team waar die ruimte wel is.
"Heel erg"? Wat ik al zei; ik doe geen projecten waar dat niet mogelijk is.:
Verder chargeer je wel heel erg
Je hebt het zelf over refactorings die een project op zich worden. Dat soort dingen moeten dus voorkomen worden. Als het zo groot wordt heb je het al veel te lang uitgesteld. En dan krijg je dus van die code bases waarvan iedereen zo iets heeft van "meh, laatmaar" en de PO's maar niet snappen waarom de kleinste features weken kosten.
Ik sla m'n PO en eventuele andere Agile bobo's er graag mee om de oren dat voor agile werken je ook agile code nodig hebt. Als je codebase al jaren aan achterstallig onderhoud opgedaan heeft, heeft het weinig zin te pretenderen dat je Agile bezig bent.
[ Voor 22% gewijzigd door Hydra op 19-06-2017 17:38 ]
https://niels.nu
Ben het ook niet oneens met je. Sterker nog ik ben het volledig met je eens.
Alleen geef je iemand het advies om zijn ontslag in te dienen omdat er onvoldoende ruimte is voor de ontwikkelaars.
Er zijn ook andere stappen die geprobeerd kunnen worden voordat je die oplossing pakt
Maar inderdaad: Als er geen verbetering zijn dan kan je inderdaad verder zoeken. Maar dat is in mijn ogen een ander probleem die je hebt dan slechte code.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Nee, ik zeg dat er als je het niet meer ziet zitten altijd nog de optie is een andere klus te zoeken. Da's wel net iets anders dan iemand aanraden ontslag in te dienen. Ik bedoel daar ook vooral mee te zeggen dat je juist als senior developer met een dergelijke ervaring en drive niet hoeft te accepteren dat er alleen maar op features gejaagd wordt. En als je liever wil blijven zitten en het gewoon accepteert prima, maar dan moet je niet klagen dat je dingen niet gedaan krijgt
M'n vorige baan was er een van slechts 6 maanden. 1 maand proberen 't team naar een hoger niveau te tillen. 1 maand proberen om er verder maar wat van te maken. 2.5 maand rustig naar een nieuwe baan gezocht. Dus ik weet echt wel hoe 't is bij een compleet prutsbedrijf te zitten.
Was nog ColdFusion ook
https://niels.nu
En weer ben ik het met je eens:
[...]
Nee, ik zeg dat er als je het niet meer ziet zitten altijd nog de optie is een andere klus te zoeken. Da's wel net iets anders dan iemand aanraden ontslag in te dienen. Ik bedoel daar ook vooral mee te zeggen dat je juist als senior developer met een dergelijke ervaring en drive niet hoeft te accepteren dat er alleen maar op features gejaagd wordt. En als je liever wil blijven zitten en het gewoon accepteert prima, maar dan moet je niet klagen dat je dingen niet gedaan krijgt
M'n vorige baan was er een van slechts 6 maanden. 1 maand proberen 't team naar een hoger niveau te tillen. 1 maand proberen om er verder maar wat van te maken. 2.5 maand rustig naar een nieuwe baan gezocht. Dus ik weet echt wel hoe 't is bij een compleet prutsbedrijf te zitten.
Was nog ColdFusion ook
Dit wordt zo wel de meeste vervelende discussie die ik ooit heb gehad
Punt wat ik wilde maken is dat ik jouw reactie (zoals ik het las) wel heel erg extreem is. Jij hebt inmiddels jouw standpunt verduidelijkt waardoor mijn opmerking dat jij "heel erg" chargeert terug kunnen brengen naar "een beetje" gechargeerd (zoals je het oorspronkelijk bedoelde).
Maar terug on-topic (zover mogelijk in de Devschuur): 6 maanden is wel extreem kort, dat moet wel erg bagger zijn geweest.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
/u/142011/crop65b383c6c6c2f_cropped.png?f=community)
:strip_icc():strip_exif()/u/137799/pp.jpg?f=community)
Wat is jullie ervaring met open kantoorruimtes? Wellicht ben ik hypergevoelig, maar ik vind dit een enorm storende trend in de IT-wereld. Onze designers vinden het ogenschijnlijk fantastisch, maar ik heb geregeld gewoon concentratie nodig. Ja, ik heb een noise canceling koptelefoon, maar ik heb ook niet altijd zin om deze op te hebben. Afleiding is voor mij als developer de grootste vijand van lekker productief bezig zijn. Gelukkig zijn wij recentelijk van één grote ruimte (20+ developers) naar teamruimtes gegaan. Ik zit nu met 3 andere developers, een product owner en een tester in een kantoor en dat is gewoon goed te doen .
Ter verduidelijking, zoiets dus:
Een poosje terug was ik in het Beatrixgebouw bij de Jaarbeurs in Utrecht. Zit vol met hippe startups die dan in één hele grote ruimte zitten op hun soort van kantooreilandjes. Daar had ik laatst dus een zakelijk gesprek, stond er 5 minuten later ineens een groep vrouwen in gymkleding Pilates te doen met bijbehorende (luide) muziek. Oogstrelend, maar het voelde wel erg onprofessioneel (en ik ben niet heel formeel ingesteld doorgaans)
Dit plaatje mag natuurlijk niet ontbreken:
.Ter verduidelijking, zoiets dus:
Een poosje terug was ik in het Beatrixgebouw bij de Jaarbeurs in Utrecht. Zit vol met hippe startups die dan in één hele grote ruimte zitten op hun soort van kantooreilandjes. Daar had ik laatst dus een zakelijk gesprek, stond er 5 minuten later ineens een groep vrouwen in gymkleding Pilates te doen met bijbehorende (luide) muziek. Oogstrelend, maar het voelde wel erg onprofessioneel (en ik ben niet heel formeel ingesteld doorgaans)
Dit plaatje mag natuurlijk niet ontbreken:
Mother north, how can they sleep while their beds are burning?
:strip_icc():strip_exif()/u/246777/crop5665347035c66.jpeg?f=community)
Op zich heb ik er weinig problemen mee. Scheelt ook dat wij een enorme berg aan ruimte hebben en er zat plekken zijn voor korte meetings/syncs/kort babbelen.
Als iemand een korte vraag heeft, Slack! Heb je een langere vraag? Kom dan langs bij onze team area en sluit een laptop aan op de TV of gebruik de desktop bij de TV. Rondom onze TV is een bank met ruimte voor 8 man, een ronde tafel met stoelen eromheen en een TV aan de muur dus ruimte zat
Is het soms storend? Ja! Is het vervelend, neuh over het algemeen niet
Geniale comic trouwens! En precies de reden dat wij iedereen zo veel mogelijk naar Slack schoppen. Zodra iemand dan even een paar minuten rust heeft, kan hij/zij daarop reageren
[ Voor 13% gewijzigd door Swedish Clown op 20-06-2017 00:24 ]
Always looking for developers wanting to work with Erlang.
:strip_icc():strip_exif()/u/68028/crop5c0ef8207f712_cropped.jpeg?f=community)
Flexplekken zijn inderdaad kut. Ik kan al m'n zooi dan ook lekker laten liggen
Hell, wij hebben een Beer o Clock dashboard, een Awesomeness poster en ik heb een metalen bord met "No coffee, No job" boven m'n bureau hangen. Scheelt ook wel dat wij HEEEL zelden externen over onze verdieping hebben lopen dus iedereen kan er wel de lol van inzien (Inclusief onze CTO, die onze Beer o Clock werkelijk geniaal vond 
)
Always looking for developers wanting to work with Erlang.
Open ruimtes vind ik bij mij op het werk (bijbaan) niet heel storend. Maar we zitten dan ook in een klein kantoortje met net 4/5 mensen .
.
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
:strip_icc():strip_exif()/u/174665/crop5f3505845c31b_cropped.jpeg?f=community)
End-users are clingy complaining dipshits who will never ever be grateful for any concession you make. The moment you shut out their shrill, tremulous voices, the happier you will be for it.
Ik weet niet hoe groot die applicatie is en hoe groot het team is dat eraan werkt maar als je zulke doorloop tijden noemt is het dan niet beter om van scratch te gaan beginnen
?-
Over de open ruimtes:
Ligt een beetje aan hoe open de ruimte is. Ik vind aparte hokjes waar 1 iemand in zit juist kut en een muur scheppen bij samenwerking. Ik vind het zelf veel prettiger als je als team bij elkaar zit (dus PO + team leden).
Ik vind ook dat je gewoon je mond mag opentrekken als het te luidruchtig is, want wellicht heeft de ander het helemaal niet door. Ik kan zelf namelijk soms ook wel aanwezig zijn en dat heb ik dan niet door. Vind het dan vervelender als mensen dan geërgerd gaan zitten doen terwijl een vraag het op had kunnen lossen.
Nothing to see here!
:strip_exif()/u/259931/stuiterbal2.gif?f=community)
Huidige werk is een kantoortuin, maar wel met eilanden, dividers en noise reduction panelen aan het plafond (echt een aanrader!). Ik kom hier prima mee uit de voeten, maar ik weet dat sommige collega's het niet zo heel jofel vinden. Gelukkig heeft iedereen afgelopen Kerst de mogelijkheid gehad een mooie noise cancelation koptelefoon te versieren. Als ik me echt even wil concentreren dan gaat er takkeherrie op de koptelefoon en gaan
Nieuwe werk heeft kantoren per team. Ben benieuwd hoe dat bevalt.
Nieuwe werk heeft kantoren per team. Ben benieuwd hoe dat bevalt.
Read the code, write the code, be the code!
:strip_icc():strip_exif()/u/517178/crop5e8dca00a16b9.jpeg?f=community)
Dat is meestal omdat ze dan muziek keihard opstaan & meestal nog met hun telefoon bezig zijn
(Of geen f*ck om andere geven, denken alleen op de wereld te zijn)
Merk dat de gemiddelde fietser juist geen "geld" heeft voor zo'n dure noise cancelling device.
[ Voor 9% gewijzigd door Ryur op 20-06-2017 10:54 ]
Achja als ik ook op de fiets ben wacht ik nog op de eerste die van schrik z'n telefoontje weg mikt:
[...]
Dat is meestal omdat ze dan muziek keihard opstaan & meestal nog met hun telefoon bezig zijn
(Of geen f*ck om andere geven, denken alleen op de wereld te zijn)
(mijn remmen klinken thans als of er een giga goederentrein vol in de ankers gaat, dat gaat kennelijk nog wel door de sound-bubble van de meeste individuen heen).
Maar goed dan kan ik je verder ook niet helpen .. kom niet verder dan incidenteel eens oordopjes.
[ Voor 8% gewijzigd door gekkie op 20-06-2017 10:56 ]
Ik heb het al eens voorgesteld, maar het probleem is dat de huidige code al meer dan 10 jaar in ontwikkeling is. De personen die er over gaan durven een complete rewrite niet aan. Persoonlijk denk ik dat het verstandiger zou zijn om het wel te doen, maar ach. 1 vs 3:
[...]
Ik weet niet hoe groot die applicatie is en hoe groot het team is dat eraan werkt maar als je zulke doorloop tijden noemt is het dan niet beter om van scratch te gaan beginnen
Een complete rewrite valt bijna altijd tegen. Er zit meestal toch een hoop "kennis" in de bestaande implementatie. Allemaal gekke edge-cases waar de gebruikers nu aan gewend zijn. Als je een complete rewrite doet zul je ook in 1 keer alle functionaliteit opnieuw moeten maken, anders is de adoptie van het nieuwe systeem meestal niet voldoende.:
[...]
Ik heb het al eens voorgesteld, maar het probleem is dat de huidige code al meer dan 10 jaar in ontwikkeling is. De personen die er over gaan durven een complete rewrite niet aan. Persoonlijk denk ik dat het verstandiger zou zijn om het wel te doen, maar ach. 1 vs 3
Meestal is het beter om gewoon stuk voor stuk delen te vervangen totdat uiteindelijk het hele product vervangen is.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Met @Woy. Een rewrite wordt vaak onderschat. Ik heb het zelf ook meegemaakt bij een vorige werkgever. Daar werd een ETL tool, complete bagger, herschreven (ook nog van C# naar Java, cross-platform). Een paar jaar later hadden we een nieuwe versie van dezelfde tool. Die was ook bagger, maar bagger op z'n eigen unieke manier
Wat daar gedaan had moeten worden was gewoon die tool scrappen en een fatsoenlijke API aanbieden. De tijdsinverstering was hoe dan ook niet terug te verdienen.
Wat daar gedaan had moeten worden was gewoon die tool scrappen en een fatsoenlijke API aanbieden. De tijdsinverstering was hoe dan ook niet terug te verdienen.
https://niels.nu
/u/296460/beaker_s.png?f=community)
Helemaal mee eens. Per stuk refactoren werkt een stuk beter. We zien hier zelfs aan de gang gegaan met een nieuwe namespace, zodat het ook duidelijk is wat de nieuwe en oude code is. En tijdens het refactoren kom je inderdaad best vaak een bugfix of corner-case tegen die ik echt vergeten zou zijn als ik het opnieuw zou schrijven.
Ik snap wat je zegt, maar toch overdrijf je behoorlijk over mijn geval. Ik probeer juist duidelijk te maken hoe het nu bij mij in de praktijk werkt. Een complete refactor is gewoon niet te doen, omdat het te veel tijd kost, lastig onder controle te houden valt (ook met testen e.d.) en dat er ook nog aan nieuwe functies gewerkt moet worden.
Ik heb juist een aantal collega's die het erg leuk vinden om te leren hoe je implementatie veel leesbaarder kunt coderen, maar dat kost tijd, ook om collega's mee te krijgen in mijn gedachtengang. Zoals jij hier nu de boel neerzet, kan ik me niet voorstellen dat je echt lekker samenwerkt met collega's die mogelijk wel eens een andere mening hebben of nog veel moeten leren. Praktijk en de ideale wereld liggen nogal eens ver uit elkaar
[ Voor 46% gewijzigd door Marcj op 20-06-2017 13:30 ]
Je zou ook kunnen kijken of je het systeem eerst kan opsplitsen in onderdelen, zodat je dan wel in onderdelen kan refactoren. Dan heb je dus eerst een set aan duidelijke componenten met bijbehorende API's gedefinieerd en kun je toch de impact van elke stap enigszins beperkt houden. Een rewrite eindigt veel te vaak in een ramp.
Als je niet direct alle gebruikers over zet, dan zit je nog een hele tijd met 2 systemen die je moet ondersteunen en onderhouden. Ik weet niet of je daar echt blij van wordt
[ Voor 7% gewijzigd door Marcj op 20-06-2017 13:37 ]
Dat is wat we nu proberen te doen en dus nog wel een paar jaar mee bezig zijn.
Dat ben ik met je eens, maar in dit geval sluit de basis al niet meer aan bij onze wensen. Daar wordt nu al een behoorlijke tijd omheen gehacked.
Mwoah, dat gebeurt nu ook al, maar juist bij het product waarbij het eigenlijk echt zou moeten, gebeurt het niet[...]
Als je niet direct alle gebruikers over zet, dan zit je nog een hele tijd met 2 systemen die je moet ondersteunen en onderhouden. Ik weet niet of je daar echt blij van wordt
Hoe dan ook was mijn eerste comment meer een blijk van begrip voor de situatie. De discussie is verder uiteraard interessant, maar daar gaan we nergens komen. Ik kan namelijk niet meer over het systeem zeggen en zonder dat zal ik nooit iemand hier voor mijn kant winnen ^^ (want mijn initiële reactie als iemand een rewrite voorstelt is ook "niet doen")
Ik heb ook meerdere van deze projecten gedaan en tbh waren de meest successvolle diegene waar een goede PO gewoon van scratch af aan ging beginnen. Sommige functionaliteit moet dan hetzelfde blijven werken maar andere dingen kunnen dan meteen getoetst worden of het niet beter kan. En als je dan elke sprint of elke 2 sprints naar productie gaat dan faseer je geleidelijk die andere applicatie uit inderdaad
.
Nothing to see here!
Sinds we een nieuwe sales man hebben heb ik om een QC50 gervraagd en gekregen, en gelukkig zijn we verhuisd naar een grotere ruimte. We zaten met 11 man op ongeveer 50m2, dus de spanningen liepen nog wel eens op
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Dit topic is gesloten.