Mag mijn werkgever mijn code editor bepalen?

[Verwijderd]

En anders pas je je workflow toch aan? Lekker in Sublime werken en voor je commit ff door Dreamweaver halen.

[Question Mark]

Lxske schreef op maandag 23 januari 2017 @ 12:47:
Ik ben geen fan van Dreamweaver.

Ik geef dan aan dat een mij onvertrouwde editor niet gaat zorgen dat ik foutloos werk.

Wat is nu werkelijk het probleem om te gaan werken met Dreamweaver? Als je er nooit gebruik van maakt ga je het nooit vertrouwen. Ik hoor eigenlijk geen enkel geldig argument waarom je dit niet zou kunnen doen.

[NMe]

Lxske schreef op maandag 23 januari 2017 @ 13:06:
[...]

Zij verwachten dat (zoals hier door iemand genoemd) de highlighting de fouten aan het licht brengt. Ik vind zelf dat ik gewoon scherp moet zijn

Natuurlijk moet je scherp zijn, maar dat is geen excuus om geen hulpmiddelen te gebruiken. Da's zo'n beetje zoiets als koppig de rem in je auto niet gebruiken omdat je met terugschakelen en je handrem óók gewoon kan afremmen en tot stilstand kan komen. Het kán wel, maar het gaat je met enige intervallen problemen opleveren die gewoon heel eenvoudig voorkomen hadden kunnen worden.

Van de ene programmeur tot de andere: je komt op mijn wat arrogant en trots over door min of meer te beweren dat je het prima af kan zonder highlighting en code completion en ik zou je om die reden niet in mijn team willen hebben. Ik vind het lovenswaardig dat het bedrijf waar je voor werkt je die kans wel geeft en je zelfs ondanks fouten die je had kunnen voorkomen tóch nog met die editor heeft laten werken.

Sublime is een teksteditor. Dreamweaver is dat niet, Dreamweaver is een IDE. En hoewel ik óók geen fan ben van Dreamweaver kun je toch echt beter én sneller werken in een IDE dan in een tekstverwerker.

[ Voor 8% gewijzigd door NMe op 23-01-2017 13:44 ]

[BLACKfm]

Wellicht totaal niet relevant, maar aan wat voor foutjes moeten we denken? Ik vraag me af waarom een team bij elkaar moet komen voor een code technisch verhaal.

Alsof er één of andere stukje bancaire software wordt ontwikkeld en door een foutje er nu tonnen naar een verkeerde rekening is gestuurd.

De omschrijving komt om mij over als een strak regime, een fout die niet aan de software kan liggen als de input alleen maar 'tekst' of code is.

Lijkt me ook een gevalletje 'typ ff wat code en zodra je het gaat testen moet het hele bedrijf het direct zien, als je dan een fout hebt ga je gelijk over de knie'. Je gaat je product toch eerst testen? Of laat het reviewen door een ander? Een fout kan naar mijn idee in een organisatie niet altijd maar aan jezelf liggen als meerdere mensen erbij zijn betrokken.

TL;DR:

Wat maakt de fouten zo erg dat er een (in mijn ogen) zwaar overleg voor nodig is om je fout uitvergroot te behandelen? En waarom zou dat aan de software liggen?

[Lxske]

BLACKfm schreef op maandag 23 januari 2017 @ 13:31:
Wellicht totaal niet relevant, maar aan wat voor foutjes moeten we denken? Ik vraag me af waarom een team bij elkaar moet komen voor een code technisch verhaal.

Alsof er één of andere stukje bancaire software wordt ontwikkeld en door een foutje er nu tonnen naar een verkeerde rekening is gestuurd.

De omschrijving komt om mij over als een strak regime, een fout die niet aan de software kan liggen als de input alleen maar 'tekst' of code is.

Lijkt me ook een gevalletje 'typ ff wat code en zodra je het gaat testen moet het hele bedrijf het direct zien, als je dan een fout hebt ga je gelijk over de knie'. Je gaat je product toch eerst testen? Of laat het reviewen door een ander? Een fout kan naar mijn idee in een organisatie niet altijd maar aan jezelf liggen als meerdere mensen erbij zijn betrokken.

TL;DR:

Wat maakt de fouten zo erg dat er een (in mijn ogen) zwaar overleg voor nodig is om je fout uitvergroot te behandelen? En waarom zou dat aan de software liggen?

Je TL;DR-vragen heb ik helaas geen antwoord op. De code is inderdaad getest en niet alleen door mij. Strak regime? Wellicht. Maar goed, ik was er zelf bij toen ik hier tekende.

[jeroen3]

Voor je het weet gebruikt iedereen een andere editor en heb je tab/space hell.
Er is waarschijnlijk niet voor niets een huisstijl voor de code.

[ Voor 29% gewijzigd door jeroen3 op 23-01-2017 13:46 ]

[posttoast]

jeroen3 schreef op maandag 23 januari 2017 @ 13:46:
Voor je het weet gebruikt iedereen een andere editor en heb je tab/space hell.
Er is waarschijnlijk niet voor niets een huisstijl voor de code.

Dat is een non-argument natuurlijk, zoiets kun je in elke fatsoenlijke editor gewoon instellen.

[REDSD]

De argumentatie klinkt wat raar, je kan in elke editor in principe fouten maken.
Ik weet niet wat voor fouten het gaat, ik neem aan dat je je code ook test en naloopt?

Voor de rest kan een goede editor echt wel iets toevoegen en je leven zo veel makkelijker maken.
Visual studio, Netbeans, Intelli (jetbrains) en eclipse zijn allemaal editors die echt iets toevoegen als je programmeert.
Sublime wordt veel gebruikt, omdat het een snelle editor is, maar hij mist standaard wel wat features in vergelijking met bovenstaande editors.

[NMe]

REDSD schreef op maandag 23 januari 2017 @ 14:02:
De argumentatie klinkt wat raar, je kan in elke editor in principe fouten maken.
Ik weet niet wat voor fouten het gaat, ik neem aan dat je je code ook test en naloopt?

Voor de rest kan een goede editor echt wel iets toevoegen en je leven zo veel makkelijker maken.
Visual studio, Netbeans, Intelli (jetbrains) en eclipse zijn allemaal editors die echt iets toevoegen als je programmeert.
Sublime wordt veel gebruikt, omdat het een snelle editor is, maar hij mist standaard wel wat features in vergelijking met bovenstaande editors.

Sublime is een editor, alle andere software die je noemt zijn dat niet. Een IDE is véél meer dan alleen een editor.

[Puch-Maxi]

Waar praten we eigenlijk over, welke taal? Als ik DW hoor denk ik vooral aan webdevelopment. Maar ik kan me vergissen .

[TTLCrazy]

Lxske schreef op maandag 23 januari 2017 @ 12:47:
Ik heb een vast contract bij een groot bedrijf waar ik sinds een jaar werk, in een klein team. Bij sollicitatie werd me gevraagd welke code editor ik gebruik.
Ik gebruik Sublime, mijn collega's Dreamweaver. Ik ben geen fan van Dreamweaver.

Dit was geen probleem.

Als het toen geen probleem was, waarom is dat het nu wel ineens ?

[NMe]

TTLCrazy schreef op maandag 23 januari 2017 @ 14:09:
[...]

Als het toen geen probleem was, waarom is dat het nu wel ineens ?

...omdat ze nu hebben gemerkt dat het in de praktijk problemen oplevert?

[.oisyn]

Dat noemen ze ook wel "voortschrijdend inzicht"

[Richh]

Ik heb zelf ook een enorm sterke voorkeur voor de IntelliJ-software als het even kan. Mijn werkgever wil (sinds verhuizing) dat ik in Visual Studio werk. Nouja, dan kunnen ze er vanuit gaan dat ik daar de eerste maand(en) iets langzamer werk omdat ik mijn IDE onder controle moet krijgen. En zelfs nu nog steeds durf ik te beweren dat IntelliJ veel betere autocomplete en hints geeft, en sneller in gebruik is.

Desalniettemin blijft het mijn werkgever (en veel belangrijker: de groep collega's met wie je samenwerkt) waarmee je er samen uit moet komen. En als iedereen op jou na voor tooling X stemt, dan vind ik het niet meer dan normaal dan dat je daar in meegaat.

Ondanks bovenstaand verhaal snap ik heel goed dat werkgevers en managers er niet op zitten te wachten dat werknemers enkel in een text editor werken. Feit is dat het gevaarlijker is, feit is dat je (getraind op beide manieren) sneller bent met autocomplete en hints... Tuurlijk is het een prestatie om alles plain uit je hoofd te doen. Maar het is nogal onnodig: je werkt voor je baas en niet voor jezelf.

Heb je het al een serieuze kans gegeven?

[itsleon]

Wat ik lees, is dat het voorheen wel mocht maar er blijken nu te veel fouten in de code voor te komen en ze denken dat het te maken heeft met de editor die jij gebruikt. Ze willen nu dus dat jij dezelfde Editor/IDE gaat gebruiken als de rest van je collega's om te kijken of er dan meer fouten in de code voorkomt. Niet zo raar als je het aan mij vraagt.

Dus om je vraag te beantwoorden: Ja een werkgever kan eisen dat jij een bepaalde Editor/IDE gebruikt en daar heb je gewoon aan te houden.

[jeroen3]

Wellicht wil de werkgever niet betalen voor Sublime. Het is immers niet gratis. En er is al Adobe software gekocht.

[Blauw]

jeroen3 schreef op maandag 23 januari 2017 @ 15:51:
Wellicht wil de werkgever niet betalen voor Sublime. Het is immers niet gratis. En er is al Adobe software gekocht.

Als dat inderdaad het geval is (gaat om $70,- ) dan kan ie beter een andere baan zoeken inderdaad

Mijn stelling zou zijn: als er fouten insluipen doordat je Sublime gebruikt ipv Dreamweaver dan kan t wel eens handig zijn om te switchen. Als er gewoon fouten in zitten (losstaand van Sublime of DW) dan lijkt me 'welke IDE' niet een hele geschikte discussie voor 3 mensen.

[Rmg]

Blauw schreef op maandag 23 januari 2017 @ 16:00:
[...]

Als dat inderdaad het geval is (gaat om $70,- ) dan kan ie beter een andere baan zoeken inderdaad

Mwa, het gaat ook een beetje om het licentiebeheer natuurlijk, als systeembeheerder is het gewoon prettig als licenties centraal beheerd kunnen worden.

[hellfighter87]

Configuratiebeheer heet dat, en in het ergste geval bepaald 1 iemand voor de rest van het team wat je gebruikt. dus ja het kan.

Fouten gebeuren nou eenmaal, aan de andere kant als fouten voorkomen kunnen worden met een fatsoenlijke IDE en unit/intergration tests scheelt dat uren die je dan aan zaken kunt besteden die wel geld opleveren

[Dets]

Als dat inderdaad het geval is (gaat om $70,- ) dan kan ie beter een andere baan zoeken inderdaad

Nee hoor, ik werk bij een groot bedrijf en een tooltje op individuele basis komt er niet in, al is het maar een $1. Je loopt aan tegen licentiebeheer, ondersteuning, security, inkoop etc. De tools staan geïnstalleerd op je laptop en daar heb je het mee te doen. Een portable app kan nog net.

[Blue-eagle]

Zo had ik ooit een collega die vond dat hij prima Notepad (die van Windows) kon gebruiken. Je kon toentertijd maar 1 keer ongedaan maken, en syntax highlighting zat er niet in, code completion ook niet, helemaal niks eigenlijk. De werkgever vond dat hij Visual Studio moest gaan gebruiken, waarop zijn reactie: "Ik bepaal dat zelf wel!" - ook na de zoveelste bug die hij tijdens het typen al had kunnen oplossen...

Het klinkt alsof TS een heel ander probleem heeft. Doe je aan unit tests schrijven? Moeten unit tests eerst slagen voordat je een commit kan doen? Heb je end-to-end tests die moeten slagen voordat je een branch mag mergen met master? Heb je code linting die on commit al checkt of je voldoet aan de afgesproken standaarden?

Ik vind een IDE erg persoonlijk. Een ontwikkelaar in een team moet mogen werken waar hij het fijnste mee werkt. Als de werkgever daar iets over te eisen heeft moet hij wel met goede argumenten komen. Ik ken Dreamweaver niet maar ik weet dat Sublime talloze plugins heeft waarmee je eigenlijk ook alles kan bereiken. Ik gebruik zelf WebStorm voor mijn projecten. Als ik zou moeten switchen naar iets wat nieuw is voor mij dan zou ik daar ook niet blij van worden.

Maar als er goede redenen voor zijn: prima.

[unezra]

Waarom zou een developer zijn eigen tooling mogen kiezen en pak 'm beet een administratief medewerker niet?

[DigitalExorcist]

Bovendien is het ook zo dat als je het bedrijf verlaat (of jezelf met auto en al om een boom vouwt of weet ik veel wat), je collega's je werk 1-op-1 over moeten kunnen nemen. Tenzij het plain text is wordt dat al lastig.

Wat is het volgende.. je gebruikt thuis Linux, dus je hele bedrijfs-IT-omgeving moet alles daar maar op aanpassen zodat je aan kan melden op het domein en zo? En als je PC naar z'n grootje gaat wordt het zeker het probleem van de ICT'ers om op te lossen? I think not.

Sorry, maar je werkgever mag écht wel bepalen welke tools gemeengoed zijn.

[Rob]

unezra schreef op maandag 23 januari 2017 @ 16:39:
Waarom zou een developer zijn eigen tooling mogen kiezen en pak 'm beet een administratief medewerker niet?

Een administratief medewerker werkt meestal op een gezamenlijk stuk software (soms in de cloud)
De code die uit een IDE komt is voor elk IDE hetzelfde (als je de juiste coding-afspraken maar aanhoudt)

Mijn mening: probeer het eens (al vind ik Dreamweaver persoonlijk geen fijn product)

[unezra]

Rob schreef op maandag 23 januari 2017 @ 16:49:
[...]
Een administratief medewerker werkt meestal op een gezamenlijk stuk software (soms in de cloud)
De code die uit een IDE komt is voor elk IDE hetzelfde (als je de juiste coding-afspraken maar aanhoudt)

Die software moet vervolgens door beheer worden aangeschaft en ondersteund.

In kleinere bedrijven zul je daarin sneller meer vrijheid hebben dan in grotere, maar het is zeker niet ongewoon dat een willekeurige nieuwe medewerker niet bepaald met welke gereedschappen hij/zij zijn/haar werk moet doen.

[Brent]

unezra schreef op maandag 23 januari 2017 @ 16:39:
Waarom zou een developer zijn eigen tooling mogen kiezen en pak 'm beet een administratief medewerker niet?

Hangt van het soort developer af. Onderkant markt: je bent een inwisselbare codeklopper die CRUD applicaties 'invult', en hier heb je uiteraard micromanagende bazen. Bovenkant: je bent een tovenaar en mag daarom alles zelf beslissen. Zijkant van de markt (bedrijf niet gespecialiseerd in programmeren): zoek het maar uit, zolang het maar werkt.

Kies je werkgever goed

[eL_Jay]

Aangezien het je 'tot hier zit' raad ik je zowieso aan verder te kijken, MITS je er vertrouwen in hebt makkelijk elders een betere baan te kunnen vinden. Bepaal wat voor je zelf je vereiste minimuminkomsten zijn en ga dan iets leuks zoeken wat daarbij matcht. Ik heb namelijk een vermoeden dat er een inverse relatie zit tussen de hoeveelheid geld die een programmeur verdient en het plezier dat ie in zijn werk heeft.

[Kwistnix]

Hier werkt iedereen met wat ie wil, maar er zitten dan ook overwegend ZZP-ers.
Je ziet Macs, Linux dozen, Windows bakken. Ook met verschillende IDE's, al zijn Eclipse en InelliJ IDEA wel de meest gebruikten. Zelf zit ik op Ubuntu met Eclipse en doe ook nog wel 'ns wat met Vim. Al die verschillende kruisbestuivingen leveren hier in ieder geval geen noemenswaardige problemen op.

[mashell]

Kan mijn werkgever eisen dat ik dit gebruik?

Ja. Absoluut. Wie betaald die bepaald.

Het zit me een beetje tot hier. Als die editor een vereiste was, had ik de baan niet genomen. Dat heb ik eerder aangegeven.

Serieus? Het is een editor. Geen bureaustoel die je rug vernielt. Geen (sexuele) intimidatie of anders iets ernstigs. Het is maar een editor. Mijn advies, stel je flexibel op. Leer met de verplichte editor werken. Ze hebben het al twee keer gevraagd. Als je dat niet doet zal het je altijd aangewreven blijven worden. En terecht of onterecht als je achilleshiel gaan gelden. Het voordeel van het leren van die andere editor komt overigens helemaal bij jou. Jij hebt dan diversere ervaring en dat is handig, zowel binnen als eventueel buiten dit grote bedrijf.

[redfox314]

Sublime is wel heel kaal wat betreft assistance tegen fouten dus ik kan mij best vinden in de positie van je werkgever.

Zelf heb ik het idee dat alle 'scherp' zijn dat je IDE je kan besparen kan je toepassen op het effectieve probleem. Je kan dus met dezelfde hoeveelheid concentratievermogen in evenveel tijd een complexer probleem tackelen. Voor mij is die rekening snel gemaakt.

[WhiteDog]

Brent schreef op maandag 23 januari 2017 @ 16:55:
[...]

Hangt van het soort developer af. Onderkant markt: je bent een inwisselbare codeklopper die CRUD applicaties 'invult', en hier heb je uiteraard micromanagende bazen. Bovenkant: je bent een tovenaar en mag daarom alles zelf beslissen. Zijkant van de markt (bedrijf niet gespecialiseerd in programmeren): zoek het maar uit, zolang het maar werkt.

Kies je werkgever goed

Helemaal juist. Zelf zit ik links bovenaan

Maar wie klaagt er hier over die editor? Is dat je baas zelf of je collega's?

Had het gebruik van DreamWeaver een verschil gemaakt? Wat als je gewoon DW gebruikt, waar gaat men dan bij de volgende fout over zeuren?

Wat is de "sanctie" die je collega's krijgen als ze fouten maken?

[JustFogMaxi]

Klinkt een beetje als 'Real programmers use Vim'. Ben je te goed om in een IDE te werken? (Los daarvan, dreamweaver bestaat dat nog?)

[ Voor 4% gewijzigd door JustFogMaxi op 23-01-2017 20:17 ]

[Sissors]

Zonder zelf verstand ervan te hebben, je kan natuurlijk altijd nog op een compromis aansturen: Jij gaat een echte IDE gebruiken met code completion en de hele handel om soortgelijke fouten te voorkomen in de toekomst, maar niet Dreamweaver als dat een bagger pakket is.

[Lxske]

Nooit gedacht dat dit zoveel los zou maken!
Zoals gezegd heb ik genoeg input voor deze situatie, dus wijd ik liever niet in detail uit, maar ik reageer hieronder nog even op wat meer voorkomende vragen/stellingen.

JustFogMaxi schreef op maandag 23 januari 2017 @ 20:16:
Klinkt een beetje als 'Real programmers use Vim'. Ben je te goed om in een IDE te werken? (Los daarvan, dreamweaver bestaat dat nog?)

Haha! Terechte reactie, tuurlijk met een kern van waarheid. Ik ben bang dat ik met een IDE straks mijn daadwerkelijke codekennis kwijt ben (heb ik ook aangegeven) en dat is juist iets waar mijn ambitie ligt.
Ik vind dat code niet alleen moet werken, maar ook kloppen tot en met indents en comments aan toe. Dat komt misschien arrogant over, helaas.

WhiteDog schreef op maandag 23 januari 2017 @ 20:09:
[...]

(....)

Had het gebruik van DreamWeaver een verschil gemaakt? Wat als je gewoon DW gebruikt, waar gaat men dan bij de volgende fout over zeuren?

Deze zag ik ook vaker: de fout die ik nu had gemaakt, lag aan slecht testen. Dat had ik in iedere editor even slecht gedaan, want staat los van de editor.

Het ziet ernaar uit dat ik voor nu het moet gaan gebruiken, dus waar ze vervolgens over zouden zeuren, plaats ik hier misschien over een paar weken
Zelf zet ik vast in op werktempo.

[.oisyn]

Lxske schreef op maandag 23 januari 2017 @ 21:45:
Nooit gedacht dat dit zoveel los zou maken!

Je bent zeker nieuw hier

[BLACKfm]

Lxske schreef op maandag 23 januari 2017 @ 21:45:
Nooit gedacht dat dit zoveel los zou maken!

Dat komt vast door de rare situatie. Ik kan me bijvoorbeeld niet voorstellen dat door een fout in de code er een vergadering moet worden gehouden. Dit kan natuurlijk ook gewoon een brainstorm of debug sessie zijn, maar het komt over alsof je voor een vuurpeloton wordt gezet omdat je een ` hebt gebruikt ipv een '.

Maar dat komt dan waarschijnlijk meer doordat je niet in die details treed (en die zullen er vast ook niet toe doen, maar daar haken mensen zoals ik wel op in )

[Whatson]

jeroen3 schreef op maandag 23 januari 2017 @ 13:46:
Voor je het weet gebruikt iedereen een andere editor en heb je tab/space hell.
Er is waarschijnlijk niet voor niets een huisstijl voor de code.

[ Voor 35% gewijzigd door Whatson op 23-01-2017 22:22 ]

[Lxske]

BLACKfm schreef op maandag 23 januari 2017 @ 21:58:
[...]


Dat komt vast door de rare situatie. Ik kan me bijvoorbeeld niet voorstellen dat door een fout in de code er een vergadering moet worden gehouden. Dit kan natuurlijk ook gewoon een brainstorm of debug sessie zijn, maar het komt over alsof je voor een vuurpeloton wordt gezet omdat je een ` hebt gebruikt ipv een '.

Maar dat komt dan waarschijnlijk meer doordat je niet in die details treed (en die zullen er vast ook niet toe doen, maar daar haken mensen zoals ik wel op in )

Aha!

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[The Eagle]

Ik stapte in 1998 pas over van wordperfect 5.1 naar Word. In WP kon ik alles met de sneltoetsen. Word hoefde voor mij niet zo nodig. Maar al doende leert men en kende ik beide werelden. Wp ken ik nu nog, al zal ik er niet zo snel mee zijn. Word ken ik ook van binnen en van buiten.

Dus als jij aan een bepaalde tool gewend bent en je nieuwe WG wil dat je een andere tool gebruikt: ga er niet tegenin, maar zie het als een kans om iets extra's te leren

Enne, als ik nu nog steeds eistte dat ik alleen met WP51 zou hoeven te werken zat ik al jaren werkloos thuis. Alle software is aan de tand des tijds onderhevig, dus ook diegene die jij nu zo goed kent.

[Rmg]

Lxske schreef op maandag 23 januari 2017 @ 21:45:

Haha! Terechte reactie, tuurlijk met een kern van waarheid. Ik ben bang dat ik met een IDE straks mijn daadwerkelijke codekennis kwijt ben (heb ik ook aangegeven) en dat is juist iets waar mijn ambitie ligt.
Ik vind dat code niet alleen moet werken, maar ook kloppen tot en met indents en comments aan toe. Dat komt misschien arrogant over, helaas.

Imho is dat echt iets wat echt tussen je oren zit.

Een ide programmeert niet voor je.
En vind je nou echt dat indents handmatig invoeren iets toevoegt Ik persoonlijk bespaar me dat werk liever en check het een keer voordat ik het incheck..

En waar bestaat je code kennis dan uit? Ide's. Helpen een beetje met syntax. Programmeer concepten zijn veel belangrijker dan syntax, iets waar een ide maar beperkt mee helpt.

[ToFast]

Gewoon slikken, je eroverheen zetten en druk maken over de zaken die er echt toe doen op het werk.

Moet overigens wel zeggen dat mijn idee bij Dreamweaver i.c.m een bedrijf(je) wel een gevoel van onprofessionaliteit geeft, maar dat valt samen met de geen vrije keuze in je tools. Geen vrije keuze hoeft niet an such slecht te zijn, maar op deze wijze of omtrent Dreamweaver..Nah.). Doet me een beetje denken aan een clubje homeboys die aan het code tikken zijn zeg maar

[Sissors]

Daarom kan hij dus ook nog voorstellen een IDE te gebruiken die hij liever heeft, maar wel zulke fouten zou voorkomen in de toekomst.

Rmg schreef op maandag 23 januari 2017 @ 22:12:
[...]


Imho is dat echt iets wat echt tussen je oren zit.

Een ide programmeert niet voor je.
En vind je nou echt dat indents handmatig invoeren iets toevoegt Ik persoonlijk bespaar me dat werk liever en check het een keer voordat ik het incheck..

En waar bestaat je code kennis dan uit? Ide's. Helpen een beetje met syntax. Programmeer concepten zijn veel belangrijker dan syntax, iets waar een ide maar beperkt mee helpt.

Ik gebruik (noodgedwongen) zo'n drie verschillende editors van verschillende talen, en ik mis elke keer in de brakke editor weer iets als auto-indents. Het is niet dat ik ze vergeet, het is gewoon irritant als je weet dat er ook fatsoenlijke editors bestaan.

[Lxske]

Rmg schreef op maandag 23 januari 2017 @ 22:12:
[...]


Imho is dat echt iets wat echt tussen je oren zit.

Een ide programmeert niet voor je.
En vind je nou echt dat indents handmatig invoeren iets toevoegt Ik persoonlijk bespaar me dat werk liever en check het een keer voordat ik het incheck..

En waar bestaat je code kennis dan uit? Ide's. Helpen een beetje met syntax. Programmeer concepten zijn veel belangrijker dan syntax, iets waar een ide maar beperkt mee helpt.

O dit las blijkbaar anders dan ik bedoelde: het gaat me niet om handmatig indenten, maar überhaupt indenten wat ik nu als enige doe. Gewoon een voorbeeld overigens.

[Sissors]

Wacht, je bent de enige daar die indents gebruikt? Dit moeten we positief zien, jullie hebben nooit discussies over of je tabs als echte tabs of als spaties ingesteld moeten zijn, en hoeveel spaties dan . Tegelijkertijd is dat wel behoorlijk idioot.

[Lxske]

Sissors schreef op maandag 23 januari 2017 @ 22:24:
Wacht, je bent de enige daar die indents gebruikt? Dit moeten we positief zien, jullie hebben nooit discussies over of je tabs als echte tabs of als spaties ingesteld moeten zijn, en hoeveel spaties dan . Tegelijkertijd is dat wel behoorlijk idioot.

[WhatsappHack]

De gene die betaald, die bepaalt... Dunkt mij.

Misschien een rare vraag hoor, maar 3 foutjes in een jaar zijn toch niet zo wereldschokkend?
Of hebben we het echt over wereldwijd dood en verderf, alle stoplichten op groen, treinen die op ramkoers worden gezet, rioolwater het drinkwater inmengen, etc.?

[Richh]

Lxske schreef op maandag 23 januari 2017 @ 21:45:
Ik ben bang dat ik met een IDE straks mijn daadwerkelijke codekennis kwijt ben (heb ik ook aangegeven) en dat is juist iets waar mijn ambitie ligt.

Wat is volgens jou codekennis?

Dat je uit je hoofd weet hoe iedere functie/methode in programmeertaal X heet en wat het doet, welke variabelen je mee moet geven? Ja, daar ga je wellicht wat luier in worden met een IDE. Maar is die kennis echt 'ambitiewaardig'?

Voor mij is codekennis meer dat je weet hoe je een probleem duidelijk en clean kan oplossen, dat je weet hoe dingen werken en hoe je optimaal met de mogelijkheden omgaat. Ik zie niet in hoe een IDE dat in de weg kan staan.

Ik vind dat code niet alleen moet werken, maar ook kloppen tot en met indents en comments aan toe. Dat komt misschien arrogant over, helaas.

Deze stelling heeft niks te maken met de keuze tussen een text editor en een IDE.

Ik denk dat iedere developer graag duidelijke, overzichtelijke code schrijft die voor iedereen leesbaar is. Het schrijven van overzichtelijke, duidelijke code met indents en comments is echter ook prima mogelijk in een IDE; wellicht zelfs beter dan in een text editor.

[CH4OS]

Gomez12 schreef op maandag 23 januari 2017 @ 12:59:
Intellisense en betere code highlighting kan wel helpen om fouten sneller te spotten en te corrigeren.

Sublime is erg uitbreidbaar. Highlighting is een kwestie van smaak en theme. Intellisense is ook te installeren binnen Sublime. Ik gebruik zelf ook graag Sublime, maar op mijn werk toch maar ervoor gekozen dezelfde editor te gebruiken als de collega's (al heb ik daarin wel de vrije keuze). Het maakt het werken veel makkelijker. Was voor mij even wennen, maar heb er zoveel profijt van nu.

Tja, of het zo verstandig is om te zeggen dat het allemaal je eigen fout is?

Een andere editor voorkomt de fouten in elk geval niet. Lijkt me meer een punt om daar op in te zetten. En 3 fouten in een jaar tijd... Sorry, maar fouten maken is en blijft menselijk natuurlijk. Dus beetje overdreven dit. Zou zelf in elk geval niet graag bij een dergelijk bedrijf willen werken, als ze echt zoveel zout op een slak leggen.

[ Voor 13% gewijzigd door CH4OS op 24-01-2017 00:38 ]

[418O2]

Sorry, maar codeformatting doe je toch niet handmatig? Ik let daar nooit heel erg op. Af en toe de shortcut inrammen en alles staat weer netjes.

En je hebt echt een verkeerd idee bij een goede developer zijn. Je hoeft echt niet elke methode naam en argumenten uit je hoofd te kennen. Je moet een ide kiezen die je helpt. Intellisense-achtige tools en highlighting is alleen maar handig.

En, met alle respect, voor je eigenwijs doet over ides en indents, leer jezelf aan je werk beter te testen.

[ Voor 12% gewijzigd door 418O2 op 24-01-2017 01:16 ]

[gold_dust]

Lxske schreef op maandag 23 januari 2017 @ 12:47:
Ik heb een vast contract bij een groot bedrijf waar ik sinds een jaar werk, in een klein team. Bij sollicitatie werd me gevraagd welke code editor ik gebruik.
Ik gebruik Sublime, mijn collega's Dreamweaver. Ik ben geen fan van Dreamweaver.
Dit was geen probleem.

Wanneer ik echter een fout maak in mijn code, wordt er een overleg ingepland om te eisen dat ik dezelfde editor als zij gebruik. Dat is nu twee keer gebeurd. Ik geef dan aan dat een mij onvertrouwde editor niet gaat zorgen dat ik foutloos werk.
Nu is er toch weer iets misgegaan en staat er wederom zo'n overleg ingepland, dit keer met de manager erbij.

Het zit me een beetje tot hier. Als die editor een vereiste was, had ik de baan niet genomen. Dat heb ik eerder aangegeven.
Kan mijn werkgever eisen dat ik dit gebruik?

Ik zou het behoorlijk ongewenst vinden dat elke keer als ik een fout zou maken, er een overleg gepland zou worden. Ik zou dat interpreteren als dat er dan meer aan de hand is dan alleen onenigheid over welke editor je gebruikt. Ook omdat het vrij normaal is dat ontwikkelaars bugs produceren.

Verder zou ik ook verwachten dat ik m'n eigen tools zoals editor zou kunnen kiezen tenzij er echt zwaarwegende redenen zijn om dit niet te doen. Dat alle anderen iets anders gebruiken zou ik ook geen goede reden vinden.

[418O2]

gold_dust schreef op dinsdag 24 januari 2017 @ 10:14:
[...]

Ik zou het behoorlijk ongewenst vinden dat elke keer als ik een fout zou maken, er een overleg gepland zou worden. Ik zou dat interpreteren als dat er dan meer aan de hand is dan alleen onenigheid over welke editor je gebruikt. Ook omdat het vrij normaal is dat ontwikkelaars bugs produceren.

Verder zou ik ook verwachten dat ik m'n eigen tools zoals editor zou kunnen kiezen tenzij er echt zwaarwegende redenen zijn om dit niet te doen. Dat alle anderen iets anders gebruiken zou ik ook geen goede reden vinden.

Het klinkt inderdaad wel een beetje alsof er managers zonder dev-ervaring boven zitten die denken te weten hoe het werkt. Fouten worden gemaakt. Als je dat wil voorkomen, doe je code-reviews door anderen en schrijf je unit-tests. Ik vermoed echter dat diezelfde managers dat onzin en te tijdrovend vinden.

[Tarkin]

gold_dust schreef op dinsdag 24 januari 2017 @ 10:14:
[...]

Ik zou het behoorlijk ongewenst vinden dat elke keer als ik een fout zou maken, er een overleg gepland zou worden. Ik zou dat interpreteren als dat er dan meer aan de hand is dan alleen onenigheid over welke editor je gebruikt. Ook omdat het vrij normaal is dat ontwikkelaars bugs produceren.

Verder zou ik ook verwachten dat ik m'n eigen tools zoals editor zou kunnen kiezen tenzij er echt zwaarwegende redenen zijn om dit niet te doen. Dat alle anderen iets anders gebruiken zou ik ook geen goede reden vinden.

Afgezien dat je gelijk hebt (elke keer overleg plannen als er een bug is?) vind ik het een raar statement dat het vrij normaal is om bugs te produceren, alsof we het on purpose doen. We meoten toch streven naar zo min mogelijk bugs.

Als er iedere keer overleg is, kan het zijn dat het issues zijn die enkel naar boven komen van zodra het naar Productie gaat? M.a.w. niet goed getest en zo doorgelaten en dat daar dan klanten van last hebben?

[MeZZiN]

Even helemaal uit de discussie met editors. Dat is een discussie die elke dag opnieuw gevoerd kan worden, Nieuwe editors IDE nieuwe versies. IDE helpen niet met brakke code / slecht testen / slapende developers / geen reviews. Draai al zelf al een tijdje mee in de software wereld als developer. En niemand maar dan ook niemand schrijft foutloze code. En ja je werkgever kan je verplichten dreamweaver te gebruiken.

Maar goed (en toch stink ik er zelf in hehehe). Maar is er iets mis bij het bedrijf waar je nu werkt. Als de discussie gaat over een foutje die je maakt met het hele team besproken moet worden is niet gezond. Ik heb zelf een team van developers gehad. Als er fouten gemaakt werden door de developer sprak ik als het echt erg was ze wel aan. Anders liep ik even naar ze toe om het aan te geven en er van te leren en klaar iedereen maakt fouten simpel. Iedereen mocht zijn eigen IDE / text editor gebruiken en het maakte mij totaal niets uit het resultaat maar goed is. En zo niet dan ligt het aan de developer en zeker niet aan de IDE.

De beste oplossing hiervoor is code review na oplevering testen op een OTAP straat. En dan pas een release maken deze compleet testen op Acceptatie en dan pas naar productie. Dit kost best veel tijd maar dan van je heel veel meer af dan een IDE ooit kan. IDE is maar gereedschap het beste gereedschap kan een goede developer betere code laten maken maar in de verkeerde handen blijft het resultaat slecht. Maar ook de kwaliteit controle niet op orde is is er geen ontwikkeling in de kwaliteit waardoor vanzelf de code achteruit gaat en dus alleen maar meer bugs insluipen.

[Gomez12]

Ik vermoed dan echter ook niet dat de vergaderingen enkel om dat foutje gehouden worden...

Ik vermoed dat het meer een scala aan issues is die ontstaan door het gebruik van een editor ipv een IDE.
Bijv :
- Handmatige indenting wat de TS zegt te doen, terwijl de IDE het standaard doet oftewel tijdsverlies
- Afwijkende werkwijzes gebruiken waardoor er kleine verschillen optreden (doe even een test-run, oh je moet dan 30 dingen instellen terwijl DW het met 2 knopjes doet)
- Vanwege afwijkende werkwijzes ook geen standaard test-protocol aan de voorkant.
Etc. etc.

Elk puntje op zich is dan wel overheen te komen mits de rest goed is. Alleen tja, als ze allemaal samenkomen en er is al vriendelijk gevraagd aan TS om over te stappen, tja dan gaat het op een gegeven moment wat minder vriendelijk en in een vergadering waarin TS zijn punten mag duidelijk maken, alleen dan moeten die punten wel steekhoudend zijn.

[XyritZz]

Wat ik nog steeds niet snap; om wat voor soort fouten gaat het? Ik lees hier wel terug dat er al getest is met je code, dus functioneel zal het wel werken.

Dan lijkt het me eerder om code style te gaan o.i.d.... nu is Sublime geen IDE maar ook niet zo spartaans dat het niets kan. Installeer eens een paar plugins en configureer de boel fatsoenlijk, dan kan Sublime best veel hoor.

Als het er om gaat dat je baas niet wil betalen voor Sublime; stap over op Atom of VS Code, werken prima en kosten niets. Van Atom weet ik dat die zelfs plugins heeft om de functionaliteit van Sublime na te bootsen. Dus je bent in no-time weer in een vertrouwde omgeving aan het werk. Ik heb Atom hier draaien met autocompletion, debugging en alles. Dat is echt een light weight IDE geworden voor als ik even snel wat moet aanpassen in een project.

Verder zou ik je willen adviseren; ga ook niet te veel dwars liggen. Werken zonder syntax highlighting maakt je geen betere developer, werken zonder autocompletion maakt je geen betere developer. Beiden maken je wel minder productief, en ik vind persoonlijk dat een werkgever daar wel iets van mag zeggen.

[emnich]

Lxske schreef op maandag 23 januari 2017 @ 21:45:
Het ziet ernaar uit dat ik voor nu het moet gaan gebruiken, dus waar ze vervolgens over zouden zeuren, plaats ik hier misschien over een paar weken
Zelf zet ik vast in op werktempo.

Mooi, dat kan voor een deel echt wel opgelost worden met een goede IDE. Als je er goed gebruik van maakt en niet eigenwijs denkt dat je het zelf beter kan dan kan je echt productiever worden door een IDE.

[Compizfox]

Lxske schreef op maandag 23 januari 2017 @ 22:17:
[...]


O dit las blijkbaar anders dan ik bedoelde: het gaat me niet om handmatig indenten, maar überhaupt indenten wat ik nu als enige doe. Gewoon een voorbeeld overigens.

Wat? Lees ik dat nu goed? Je bent de enige van het bedrijf die indents gebruikt?

[ Voor 3% gewijzigd door Compizfox op 24-01-2017 13:49 ]

[ZpAz]

Compizfox schreef op dinsdag 24 januari 2017 @ 13:48:
[...]

Wat? Lees ik dat nu goed? Je bent de enige van het bedrijf die indents gebruikt?

Dat is inderdaad nog het meest schokkende van dit verhaal. En Dreamweaver verplichten is al behoorlijk schokkend.

[Gomez12]

Compizfox schreef op dinsdag 24 januari 2017 @ 13:48:
[...]

Wat? Lees ik dat nu goed? Je bent de enige van het bedrijf die indents gebruikt?

Auto-indent DW niet gewoon automatisch als die het op je scherm toont? Waardoor er in de source geen indenting plaats hoeft te vinden en iedereen zijn eigen indenting krijgt.

Waardoor alleen de mensen met testeditors handmatig moeten indenten en tijd verliezen.

[Compizfox]

Gomez12 schreef op dinsdag 24 januari 2017 @ 14:04:
[...]

Auto-indent DW niet gewoon automatisch als die het op je scherm toont? Waardoor er in de source geen indenting plaats hoeft te vinden en iedereen zijn eigen indenting krijgt.

Misschien interpreteer ik het verkeerd, maar TS had het over niet handmatig indenten, maar überhaupt indenten.

Ik ben geen beroepsprogrammeur maar als dat zo is zou ik toch snel opzoek gaan naar een betere werkgever, want het klinkt alsof er een hoop mis is bij dat bedrijf.

Waardoor alleen de mensen met testeditors handmatig moeten indenten en tijd verliezen.

Ook editors regelen indenten voor je hoor, daar heb je geen IDE voor nodig. Zelfs Notepad++ doet dat

[Hydra]

Lxske schreef op maandag 23 januari 2017 @ 21:45:
Haha! Terechte reactie, tuurlijk met een kern van waarheid. Ik ben bang dat ik met een IDE straks mijn daadwerkelijke codekennis kwijt ben (heb ik ook aangegeven)

Ik denk dat dit wel een beetje de kern van het probleem is. Jouw collega's zien bij jou fouten optreden die je met een fatsoenlijke IDE misschien niet zou maken. Jij blijft enorm koppig doen alsof een text editor je net zo effectief maakt als een echte IDE. Dit clashed en nu is het zodanig geescaleerd dat er een manager bij komt kijken.

Het is heel simpel; je werkgever betaalt jou om je kennis om te zetten naar werkende software. Als je jezelf hindert door niet de juiste tools te gebruiken betaalt hij je eigenlijk teveel. Nu kan jij het daar heel koppig niet mee eens zijn maar je hebt zelfs je collega's tegen je, om nog maar niet te spreken over je manager. Ik raad je aan die koppigheid eens te laten varen en gewoon mee te gaan met je collega's.

Om even m'n eigen situatie aan te halen: ik 'ben' Java dev en in ons vakgebied is het gebruik van een IDE standaard. Als jij zou volhouden Sublime te gebruiken i.p.v. een fatsoenlijke Java IDE zou je waarschijnlijk niet door je proefperiode heenkomen; dit is niet te verkopen naar onze klanten.

[Verwijderd]

Ik zal het beetje hard zeggen. Wie denk jij dat je bent dat je mag bepalen hoe het bedrijf ingericht word?
Ik heb al veel werkgevers gehad omdat ik me verveel na een aantal jaren. Maar er is geen werk of werkgever die 100% aan mijn wensen voldoet. Er is altijd wel iets. In de tijdsgeest van nu zou ik zeggen maak je keuze, doet ie 't of doet ie het niet?

[Pizza_Boom]

Verwijderd schreef op dinsdag 24 januari 2017 @ 15:39:
Ik zal het beetje hard zeggen. Wie denk jij dat je bent dat je mag bepalen hoe het bedrijf ingericht word?

Enerzijds ben ik het hier mee eens, anderzijds, TS heeft bij zijn solliciteren aangegeven dat hij iets wilde en dat is toen gehonoreerd. Ik vergelijk het met werktijden: Als jij bij jouw sollicitatie aangeeft dat je van 7 tot 15 wilt werken, je werkgever gaat hiermee akkoord en vervolgens een half jaar later komt je werkgever met de mededeling dat je voortaan, omdat al je collega's van 10 tot 18 werken, jij dat ook maar moet gaan doen, moet je daar dan maar klakkeloos mee akkoord gaan?

[ArnoutV]

Werktijden is toch wel substantieel iets anders dan het gebruik van het type editor.

[.oisyn]

Pizza_Boom schreef op dinsdag 24 januari 2017 @ 16:32:
en vervolgens een half jaar later komt je werkgever met de mededeling dat je voortaan, omdat al je collega's van 10 tot 18 werken, jij dat ook maar moet gaan doen, moet je daar dan maar klakkeloos mee akkoord gaan?

Maar anderzijds moet de werkgever er wel klakkeloos mee akkoord gaan dat de werknemer te weinig gedaan krijgt omdat hij niet goed gebruik lijkt te kunnen maken van de kortere overlappende periode met overige werknemers?

[zerokill]

.oisyn schreef op dinsdag 24 januari 2017 @ 16:58:
[...]


Maar anderzijds moet de werkgever er wel klakkeloos mee akkoord gaan dat de werknemer te weinig gedaan krijgt omdat hij niet goed gebruik lijkt te kunnen maken van de kortere overlappende periode met overige werknemers?

Non argument. Dat weten de werkgever en werknemer op het moment dat ze afspreken om de werktijden zo in te richten. Om daar na een half jaar op terug te komen zou inderdaad niet netjes zijn.

Overigens best heftige reacties in dit topic! Ik neem aan dat iedereen hier een favoriete tools hebben om mee te werken. Lijkt me niet meer dan redelijk dat jij je werk omgeving op een manier in probeert te richten die voor jou en je collega's zo productief mogelijk is. Als er in eerste instantie wordt aangegeven dat er daar ruimte voor is dan zie ik niet direct wat TS anders had moeten doen.

[NMe]

zerokill schreef op dinsdag 24 januari 2017 @ 17:40:
[...]


Non argument. Dat weten de werkgever en werknemer op het moment dat ze afspreken om de werktijden zo in te richten. Om daar na een half jaar op terug te komen zou inderdaad niet netjes zijn.

Bij de werktijden zou je dat kunnen zeggen (en ook daar geldt: voortschreidend inzicht en een onwerkbare situatie voor de werkgever zijn nogal zwaarwegend) maar in het geval van de TS toch echt niet. Als hij niet goed performt vanwege een koppige keuze dan moet hij gewoon overstappen op de tooling die de rest van het bedrijf gebruikt. Alternatief is dat ze hem zijn fouten direct persoonlijk aanrekenen en dan kan het reden voor ontslag zijn. Ik denk dat de TS dermate blij moet zijn met een bedrijf dat hem een jaar lang (!) laat aanklooien in een teksteditor dat hij die baan maar beter kan proberen te houden, want met die instelling red je het niet bij veel developmenttoko's.

[zerokill]

NMe schreef op dinsdag 24 januari 2017 @ 17:44:
[...]

Bij de werktijden zou je dat kunnen zeggen (en ook daar geldt: voortschreidend inzicht en een onwerkbare situatie voor de werkgever zijn nogal zwaarwegend) maar in het geval van de TS toch echt niet. Als hij niet goed performt vanwege een koppige keuze dan moet hij gewoon overstappen op de tooling die de rest van het bedrijf gebruikt. Alternatief is dat ze hem zijn fouten direct persoonlijk aanrekenen en dan kan het reden voor ontslag zijn. Ik denk dat de TS dermate blij moet zijn met een bedrijf dat hem een jaar lang (!) laat aanklooien in een teksteditor dat hij die baan maar beter kan proberen te houden, want met die instelling red je het niet bij veel developmenttoko's.

Als je de openingspost van de TS bekijkt, en nu je eigen bericht terugleest, vind je dan dat je niet een beetje heftig reageert? (Zoals wel meer mensen in dit topic...)

Overigens ben ik het helemaal eens met de opmerking dat de werkgever uiteindelijk bepaald! Ik heb zelf ook voor een bedrijf gewerkt waar in het contract was vastgelegd welke versie van de tooling gebruikt moest worden. Of dit een goed idee was is een tweede punt. De hoeveelheid tijd die ik (en collega's) kwijt waren met het vechten met de tools sloeg nergens op. Maargoed, alles was contractueel vastgelegd dus er was geen verandering mogelijk.

Aan de TS: Er zijn bedrijven waar je zelf mag bepalen wat voor gereedschap je gebruikt!

[NMe]

zerokill schreef op dinsdag 24 januari 2017 @ 18:06:
[...]

Als je de openingspost van de TS bekijkt, en nu je eigen bericht terugleest, vind je dan dat je niet een beetje heftig reageert? (Zoals wel meer mensen in dit topic...)

De TS heeft meer gereageerd dan alleen de openingspost en daar heeft hij toch echt wel laten doorschemeren hoe het zit. Het feit dat hij zélf vindt dat een tekstverwerker en een IDE uitwisselbaar zijn is tekenend en ik kan niet anders dan dat bedrijf complimenteren voor het feit dat ze hem ondanks die vastberadenheid (en mogelijk zelfs arrogantie) om Sublime te blijven gebruiken toch de kans geven om te verbeteren.

Aan de TS: Er zijn bedrijven waar je zelf mag bepalen wat voor gereedschap je gebruikt!

Er zijn er maar heel weinig die niet op zijn minst eisen dat je een fatsoenlijke IDE gebruikt.

[Brent]

NMe schreef op dinsdag 24 januari 2017 @ 18:10:
[...]


Er zijn er maar heel weinig die niet op zijn minst eisen dat je een fatsoenlijke IDE gebruikt.

Ik wist niet dat het zo afzien was in code-klop-land

[Gomez12]

zerokill schreef op dinsdag 24 januari 2017 @ 17:40:
[...]
Non argument. Dat weten de werkgever en werknemer op het moment dat ze afspreken om de werktijden zo in te richten. Om daar na een half jaar op terug te komen zou inderdaad niet netjes zijn.

Het issue is hier echter schijnbaar dat werknemer heeft gezegd dat hij zelfstandig kan werken van 7 tot 10, terwijl hij (als vergelijk) zit te duimendraaien totdat zijn collega's komen.

In zo'n situatie is het logisch dat je erop terug komt als werknemer imho.

Ik neem aan dat iedereen hier een favoriete tools hebben om mee te werken. Lijkt me niet meer dan redelijk dat jij je werk omgeving op een manier in probeert te richten die voor jou en je collega's zo productief mogelijk is. Als er in eerste instantie wordt aangegeven dat er daar ruimte voor is dan zie ik niet direct wat TS anders had moeten doen.

Het issue is hier voornamelijk : Voor jou en je collega's zo productief mogelijk is != Doen waar je zin in hebt.

zerokill schreef op dinsdag 24 januari 2017 @ 18:06:
[...]
Aan de TS: Er zijn bedrijven waar je zelf mag bepalen wat voor gereedschap je gebruikt!

Er zijn bar weinig bedrijven waar je met contra-productieve tools mag komen aanzetten hoor.
En als je zelf alleen voor jezelf gaat zitten indenten tja dan gaat het al heel snel contra-productief zijn hoor.

Brent schreef op dinsdag 24 januari 2017 @ 18:27:
[...]
Ik wist niet dat het zo afzien was in code-klop-land

Dat is geen afzien, dat is the right tool for the right job gebruiken...
En veelal heeft een bedrijf door schade en schande geleerd wat ze wel willen, dan willen ze onbekende tools nog wel eens een kans geven (zoals hier) maar als het niet werkt dan werkt het niet en dan moet je je maar conformeren.

[Lxske]

De felheid in sommige reacties vind ik niet nodig.
Dat terzijde wil ik een ding rechtzetten, want het voorbeeld dat ik gaf blijft uit de context gerukt worden. Ik gebruik allerlei plug-ins in Sublime, waaronder auto-indent.

[NMe]

Lxske schreef op dinsdag 24 januari 2017 @ 18:40:
De felheid in sommige reacties vind ik niet nodig.
Dat terzijde wil ik een ding rechtzetten, want het voorbeeld dat ik gaf blijft uit de context gerukt worden. Ik gebruik allerlei plug-ins in Sublime, waaronder auto-indent.

Dat verandert er niks aan dat het geen IDE is. Ongeacht hoeveel plugins je erin stopt is het nog steeds een tekstverwerker. Een IDE geeft code completion, vertelt je op welke manier je functies mag (moet) aanroepen, laat zien dat je code syntactisch niet in orde is, laat je control + klikken op een functienaam om naar de definitie te springen, integreert testing en deployments, heeft een debugger aan boord, enz. enz. enz.

[JaQ]

Hoe zit het met de licentie van sublime?

(Een van de redenen waarom werkgevers sturen op tools is licentiekosten)

En intergratie met andere tooling? (Git, / Adobe Cloud of zo?)

[ Voor 22% gewijzigd door JaQ op 24-01-2017 20:01 ]

[.oisyn]

zerokill schreef op dinsdag 24 januari 2017 @ 17:40:
[...]


Non argument. Dat weten de werkgever en werknemer op het moment dat ze afspreken om de werktijden zo in te richten. Om daar na een half jaar op terug te komen zou inderdaad niet netjes zijn.

Helemaal geen nonargument. Ik stel voor dat je aandachtig naar de formulering van mijn post kijkt. Mijn punt is nou juist dat de werknemer in de praktijk meer problemen met de tijden heeft dan je wellicht zou verwachten. Bijvoorbeeld omdat hij een wat meer hands-on begeleiding nodig heeft, of niet in staat is eventuele vragen te stellen in de overlappende uren omdat hij de antwoorden nodig heeft als hij alleen is. Of omdat hij sowieso geen zak doet als hij alleen is. Trekt de werkgever in dat geval aan het kortste eind? Natuurlijk niet.

[ Voor 7% gewijzigd door .oisyn op 24-01-2017 20:16 ]

[zerokill]

.oisyn schreef op dinsdag 24 januari 2017 @ 20:13:
[...]

Helemaal geen nonargument. Ik stel voor dat je aandachtig naar de formulering van mijn post kijkt. Mijn punt is nou juist dat de werknemer in de praktijk meer problemen met de tijden heeft dan je wellicht zou verwachten. Bijvoorbeeld omdat hij een wat meer hands-on begeleiding nodig heeft, of niet in staat is eventuele vragen te stellen in de overlappende uren omdat hij de antwoorden nodig heeft als hij alleen is. Of omdat hij sowieso geen zak doet als hij alleen is. Trekt de werkgever in dat geval aan het kortste eind? Natuurlijk niet.

offtopic: Dat hangt volledig af van de situatie in het bedrijf en de bestaande mores. Punt blijft alleen dat je een afspraak hebt gemaakt met je werkgever om van 7 tot 15 te werken. Als dit in de praktijk niet mogelijk is dan had de werkgever die afspraak niet moeten maken. En ik denk dat je het met me eens bent dat het op zijn minst niet netjes is om daar op terug te komen. Zoals ik dat geformuleerd heb in mijn post.

Gomez12 schreef op dinsdag 24 januari 2017 @ 18:33:
[...]

Het issue is hier echter schijnbaar dat werknemer heeft gezegd dat hij zelfstandig kan werken van 7 tot 10, terwijl hij (als vergelijk) zit te duimendraaien totdat zijn collega's komen.

In zo'n situatie is het logisch dat je erop terug komt als werknemer imho.

In zo'n situatie is het logisch inderdaad. Maar nogmaals, als werkgever, denk goed na voor je een dergelijke afspraak maakt. Want als je er op terug moet komen dan mag je als werknemer terecht opmerken dat er iets niet goed is gegaan.

[...]

Er zijn bar weinig bedrijven waar je met contra-productieve tools mag komen aanzetten hoor.
En als je zelf alleen voor jezelf gaat zitten indenten tja dan gaat het al heel snel contra-productief zijn hoor.

Contra-productieve tools inzetten wordt inderdaad door bar weinig bedrijven ondersteund. Maar je maakt hier ook wel een stap van "je eigen tools gebruiken" naar "je eigen contra-productieve tools gebruiken".

Ik werk bij een bedrijf waar we vrij zijn om onze eigen setup te gebruiken. Dit heeft voordelen en nadelen. We werken allemaal in Vim, we hebben allemaal onze eigen plugins, sneltoetsen en instellingen. Het werkt erg goed totdat je een keer de computer van een collega moet gebruiken. Andere plugins, sneltoetsen, en complete desktop omgevingen die je niet gewend bent om te gebruiken

alvast @NMe: Het gaat hier om VHDL werk. Hier is geen goede IDE voor beschikbaar (althans naar onze mening). Wij zouden al bijzonder blij zijn met een simpele lint tool om wat simpele foutjes eruit te halen.

NMe schreef op dinsdag 24 januari 2017 @ 19:04:
[...]

Dat verandert er niks aan dat het geen IDE is. Ongeacht hoeveel plugins je erin stopt is het nog steeds een tekstverwerker. Een IDE geeft code completion, vertelt je op welke manier je functies mag (moet) aanroepen, laat zien dat je code syntactisch niet in orde is, laat je control + klikken op een functienaam om naar de definitie te springen, integreert testing en deployments, heeft een debugger aan boord, enz. enz. enz.

https://github.com/Rip-Rip/clang_complete voor Vim en Sublime. Deze plugin gebruikt Clang voor code completion, static analysis, etc. Xcode doet in feite precies hetzelfde. Die roept ook Clang aan voor dit soort features.

Het zal sowieso enorm per taal verschillen. Voor Java/C# werk moet ik er niet aan denken om zonder een IDE te werken. C, C++, Python, VHDL, ... werkt prima in iedere tekstverwerker of command line.

Misschien interessant om een tooling topic te openen ergens! Daar kunnen vast wat leuke (_{en opbouwende}) discussies uit voort komen!

[ Voor 5% gewijzigd door zerokill op 24-01-2017 22:34 ]

[.oisyn]

zerokill schreef op dinsdag 24 januari 2017 @ 22:25:
[...]


offtopic: Dat hangt volledig af van de situatie in het bedrijf en de bestaande mores. Punt blijft alleen dat je een afspraak hebt gemaakt met je werkgever om van 7 tot 15 te werken. Als dit in de praktijk niet mogelijk is dan had de werkgever die afspraak niet moeten maken. En ik denk dat je het met me eens bent dat het op zijn minst niet netjes is om daar op terug te komen. Zoals ik dat geformuleerd heb in mijn post.

Op dezelfde manier heb je ook afspraken gemaakt dat er 8 uur gewerkt wordt, niet dat je 3 van die 8 uur uit je neus zit te eten door eigen toedoen.

[CH4OS]

DonJunior schreef op maandag 23 januari 2017 @ 13:03:
Precies dit! Als de editor kan voorkomen dat jij foute code incheckt dan zou ik op een gegeven moment als team ook aankaarten om dezelfde editor of addons te gebruiken. Het punt hier is nu dat er foute code wordt ingecheck wat extra tijd kost wat simpel voorkomen had kunnen worden door een slimmere editor te gebruiken.

Ik durf te wedden dat als jij gewoon een editor hebt die wel snel jou fouten kan zien en kan aangeven dat je iets fout doet. Dat het je baas geen zak uitmaakt dat je een andere editor gebruikt.
Nu maakt men extra uren om fouten te corrigeren die voorkomen hadden kunnen worden.

Sorry, maar dit is totale onzin. De code wordt immers niet door de editor ingeklopt. Als een editor wel de fout zou aangeven, kan je als je niet oplet, die foutieve code ook gewoon pushen / commiten. Wil je echt fouten voorkomen, moet je afspraken maken en besluiten welke coding standard je gebruikt en die valideer je middels een linter, wat voor de TS lastig is, aangezien er geen goede linters zijn voor de taal waarin hij programmeert. Een andere optie; wellicht staat de highlighter niet goed ingesteld.

Om voor een fout iemand direct op het matje te roepen voor een whooping 3x per jaar is ook wel lichtelijk overdreven. Het is niet dat dergelijke fouten uren aan tijd kosten. De overleggen die de TS krijgt nav een fout, zullen dan meer tijd kosten (en geld, want in elk geval twee medewerkers kunnen op dat moment niet werken, zoals de fout oplossen) en als ik alles zo lees, zal het eerder contraproductief werken dan dat het écht iets bijdraagt.

Ik denk dat het voor de TS verstandiger is om een bedrijf te zoeken waar men meer kennis van zaken heeft en wel op een normale manier omgaat met mensen en op een beter niveau programmeren.

[ Voor 29% gewijzigd door CH4OS op 24-01-2017 23:25 ]

[Gomez12]

JaQ schreef op dinsdag 24 januari 2017 @ 19:58:
Hoe zit het met de licentie van sublime?

(Een van de redenen waarom werkgevers sturen op tools is licentiekosten)

En intergratie met andere tooling? (Git, / Adobe Cloud of zo?)

Dan heb jij denk ik heel verkeerde werkgevers gehad. Directe licentiekosten zijn bijna alleen relevant bij incidentele gebruikers.

Als iemand het 20 uur per week gebruikt voor een jaar lang, dan mag het heel wat kosten wil je het er niet uitkrijgen.

Alleen veelal zijn werkgevers bang voor indirecte kosten en dat is wel een reeel gevaar. Als de hdd van de TS crashed, hoeveel tijd kost het dan voordat TS echt weer 100% aan het werk is?
Een standaard pc kan je zo clonen en de image opzij zetten op een stukje vrije schijfruimte zodat bij een hdd crash je een nieuwe hdd erin douwt, image restoren en klaar.
Alleen eigen tooltjes en plugins erbij hebben de neiging om niet in dat traject mee te lopen en dan heb je al snel zoiets van : Welke plugin was dat ook alweer die ik gebruikte, ik ga wel even een uurtje googlen of er is een nieuwe versie van beschikbaar die net iets anders doet etc. etc. En opeens is de medewerker 2 dagen minder productief vanwege een hdd-crash.

En minder productieve medewerkers dan gaat de geld-teller opeens heel snel heel erg hard lopen.

CH40S schreef op dinsdag 24 januari 2017 @ 23:15:
[...]
Sorry, maar dit is totale onzin. De code wordt immers niet door de editor ingeklopt. Wellicht staat de highlighter niet goed ingesteld, om daarvoor iemand op het matje te roepen voor een whooping 3x per jaar is ook wel lichtelijk overdreven. Het is niet dat dergelijke fouten uren aan tijd kosten.

Ehm, hij zegt dat de code getest is door hem en door iemand anders, ik vermoed dus dat het de test-fase voorbij is gekomen. Dan kost het wel al snel uren aan tijd...

En het issue is juist dat wellicht de highlighter niet goed ingesteld staat, niemand zit er op te wachten dat Lxske uren / dagen gaat steken in het controleren / instellen van de highlighter, dat is allemaal niet-productieve tijd.
Er is niemand anders met verstand van zaken qua deze specifieke highlighter oftewel het kan veel tijd gaan kosten en bovenal kan er daarin ook weer een foutje gemaakt worden waardoor je over 2 weken weer in hetzelfde schuitje zit. Waarom zou je dat allemaal willen als er gewoon al een standaard highlighter is inclusief tig andere standaard dingen waar het bedrijf al volop gebruik van maakt.

Het bedrijf heeft het geprobeerd, maar TS heeft het niet waar kunnen maken dat hij het in Sublime net zo goed kan, oftewel ipv dat er meer uren in Sublime gestoken gaan worden wordt er aan TS gevraagd om zich te conformeren.

[Pizza_Boom]

NMe schreef op dinsdag 24 januari 2017 @ 17:44:
Ik denk dat de TS dermate blij moet zijn met een bedrijf dat hem een jaar lang (!) laat aanklooien in een teksteditor dat hij die baan maar beter kan proberen te houden, want met die instelling red je het niet bij veel developmenttoko's.

Wellicht is/was de input van TS, en dat hoeft niet eens in kwaliteit van de code te zijn, dusdanig dat het bedrijf er evengoed een meerwaarde in zag en nu probeert die meerwaarde te verhogen door ofwel alles werkbaarder te maken door verbeterde uitwisselbaarheid met collegae ofwel door zijn code kwalitatief op te krikken?

[avotar]

Uiteindelijk wist TS waar hij aan toe was toen hij er begon.
Dat het al die tijd oogluikend is toegestaan, komt ongetwijfeld door het niveau van TS.
Maar goed, als je dan struikelt en anderen de problemen moeten oplossen, dan moet je toch overwegen te schikken.

Waar ik nu werk gebruiken ze ook een volledig ander pakket om te coderen dan wat ik destijds gewend was. Maar als je een decent programmeur bent, pas je jezelf wel weer aan. Ook al gaat dat dan in het begin trager dan je zou willen.


Valt me wel op hoe een deel van de reageerders zo fel zijn over het feit dat er uberhaupt regels zijn hierover.

[DonJunior]

CH40S schreef op dinsdag 24 januari 2017 @ 23:15:
[...]
Sorry, maar dit is totale onzin. De code wordt immers niet door de editor ingeklopt. Als een editor wel de fout zou aangeven, kan je als je niet oplet, die foutieve code ook gewoon pushen / commiten. Wil je echt fouten voorkomen, moet je afspraken maken en besluiten welke coding standard je gebruikt en die valideer je middels een linter, wat voor de TS lastig is, aangezien er geen goede linters zijn voor de taal waarin hij programmeert. Een andere optie; wellicht staat de highlighter niet goed ingesteld.

[..]

Je spreekt jezelf een beetje tegen. Ik geef namelijk aan dat de code editor fouten kan voorkomen (bv m.b.v. IntelliSense) en dus kan voorkomen dat jij foute code incheckt (immers als de code niet compiled mag je ook niet inchecken) Dat doe je af als "totale onzin."

Vervolgens herhaal je eigenlijk mijn verhaal door te zeggen dat je afspraken moet maken over coding standards en validatie te doen via een linter.

TS gebruikt nu een editor zonder IntelliSense (of linter.. hoe je het wenst te noemen) en daardoor wordt er foute code ingecheckt waardoor het team in de problemen komt. (kan me zo voorstellen dat zij code pullen en vervolgens met een defecte solution zitten)
Dit kan allemaal simpel voorkomen worden door samen afspraken te maken (wat je zelf ook al aangeeft) en een goede code editor te gebruiken die dergelijke compile errors (of andere fouten) kan aangeven.

Volgens mij zijn we het dus gewoon met elkaar eens hier.

[Hydra]

zerokill schreef op dinsdag 24 januari 2017 @ 17:40:
Overigens best heftige reacties in dit topic! Ik neem aan dat iedereen hier een favoriete tools hebben om mee te werken.

Tuurlijk. Ik ken Dreamweaver zelf niet maar 'hier' is het zo dat de meeste Java devs IntelliJ gebruiken met een paar dino's die nog met Eclipse werken. Dat is beiden 'prima'. Maar als iemand hier (om maar wat te noemen) met UltraEdit aan de slag gaat wordt 'em toch echt gevraagd z'n werk serieus te gaan nemen. Een IDE is veel meer dan een simpele text editor.

CH40S schreef op dinsdag 24 januari 2017 @ 23:15:
[...]
Sorry, maar dit is totale onzin. De code wordt immers niet door de editor ingeklopt. Als een editor wel de fout zou aangeven, kan je als je niet oplet, die foutieve code ook gewoon pushen / commiten. Wil je echt fouten voorkomen, moet je afspraken maken en besluiten welke coding standard je gebruikt en die valideer je middels een linter, wat voor de TS lastig is, aangezien er geen goede linters zijn voor de taal waarin hij programmeert. Een andere optie; wellicht staat de highlighter niet goed ingesteld.

Als jij een linter kan vinden die mij verhindert bugs te introduceren dan hoor ik 't graag

Meer serieus: het is geen 'of' verhaal, het is 'en'. Alle tooling die je gebruikt, je IDE en wat er in je build gebeurt, kan bijdragen aan een betere kwaliteit van je software.

[ Voor 43% gewijzigd door Hydra op 25-01-2017 09:22 ]

[JaQ]

Gomez12 schreef op dinsdag 24 januari 2017 @ 23:26:
Dan heb jij denk ik heel verkeerde werkgevers gehad. Directe licentiekosten zijn bijna alleen relevant bij incidentele gebruikers.

Als iemand het 20 uur per week gebruikt voor een jaar lang, dan mag het heel wat kosten wil je het er niet uitkrijgen.

Alleen veelal zijn werkgevers bang voor indirecte kosten en dat is wel een reeel gevaar. Als de hdd van de TS crashed, hoeveel tijd kost het dan voordat TS echt weer 100% aan het werk is?
Een standaard pc kan je zo clonen en de image opzij zetten op een stukje vrije schijfruimte zodat bij een hdd crash je een nieuwe hdd erin douwt, image restoren en klaar.
Alleen eigen tooltjes en plugins erbij hebben de neiging om niet in dat traject mee te lopen en dan heb je al snel zoiets van : Welke plugin was dat ook alweer die ik gebruikte, ik ga wel even een uurtje googlen of er is een nieuwe versie van beschikbaar die net iets anders doet etc. etc. En opeens is de medewerker 2 dagen minder productief vanwege een hdd-crash.

En minder productieve medewerkers dan gaat de geld-teller opeens heel snel heel erg hard lopen.

De direct kosten zijn inderdaad niet het punt, en voor een kleine organisatie heb je ongetwijfeld gelijk. In een grote organisatie spelen ook zaken mee als contractbeheer, onderhandelen met leveranciers etc. En dan is het nog maar hopen dat je werknemer geen tooltje heeft gekozen waardoor je bedrijf helemaal incompliant is met bijvoorbeeld Java licenties (recent hot topic) of dat een developer iets op vmware heeft gezet waardoor de kosten exploderen. En dat zijn enkel de kosten die je rechtstreeks aan licenties kan relateren.

Daarnaast de overdraagbaarheid van werk bij vrije toolkeuze niet gegarandeerd. Als iedere developer maar een beetje zijn eigen tooling kiest wordt het een janboel (ik chargeer bewust), juist in een grote organisatie is dat niet wat je wilt. Straks moet je zestien verschillende build omgevingen onderhouden omdat er allemaal eigenwijze mannetjes zitten die vinden dat hun tooltje beter is. (vandaar ook dat de open source wereld vol zit met "yet another" and "bla is not bla" tooltjes). En dan nog web-based tooltjes die vol zitten met security issues (en die gepatched moeten worden, etc). Compliancy is a bitch. Al die kosten wegen heel dik op tegenover een eventuele productiviteitsverhoging door vrije tool keuze.

Uiteraard zit de sweet-spot in het midden, nuance wint altijd: open staan voor verandering (= niet star) maar tegelijkertijd ook niet je koers wijzigen door iedere poep of scheet die bedacht wordt door een willekeurig persoon in je bedrijf. Niemand is gebaad bij een Mexican stand-off, maar soms is een alternatief nou eenmaal handiger/beter voor de rest van de organisatie.

[CH4OS]

DonJunior schreef op woensdag 25 januari 2017 @ 08:05:
Je spreekt jezelf een beetje tegen. Ik geef namelijk aan dat de code editor fouten kan voorkomen (bv m.b.v. IntelliSense) en dus kan voorkomen dat jij foute code incheckt (immers als de code niet compiled mag je ook niet inchecken) Dat doe je af als "totale onzin."

Vervolgens herhaal je eigenlijk mijn verhaal door te zeggen dat je afspraken moet maken over coding standards en validatie te doen via een linter.

TS gebruikt nu een editor zonder IntelliSense (of linter.. hoe je het wenst te noemen) en daardoor wordt er foute code ingecheckt waardoor het team in de problemen komt. (kan me zo voorstellen dat zij code pullen en vervolgens met een defecte solution zitten)
Dit kan allemaal simpel voorkomen worden door samen afspraken te maken (wat je zelf ook al aangeeft) en een goede code editor te gebruiken die dergelijke compile errors (of andere fouten) kan aangeven.

Volgens mij zijn we het dus gewoon met elkaar eens hier.

Highlighting weerhoudt je er niet van foutieve code tóch in te checken. Highlighting gebruiken minimaliseert fouten, je moet ze zelf immers ook nog eerst opmerken en dat kan soms best wel tricky zijn nog, weet ik uit ervaring, omdat je daar gewoonweg makkelijk overheen kijkt, al is dat natuurlijk ook afhankelijk van welke theme binnen de highlighting je gebruikt en/of de applicatie waarmee je ontwikkeld.

Je kan daarmee niet voorkomen dat je fouten maakt en er dus ook niet op vertrouwen. Daar heb je de peer reviews en (tot op zekere hoogte) de linter voor. Als het daar ook doorheen komt, is het niet meer alleen de fout van de commiter, maar ook van de reviewer. Het is niet dat (syntax) highlighting alle fouten kan voorkomen, maar dat is gewoonweg niet waar, meer dan een hulpmiddel is het dus niet. Ook in goed geschreven code (waarover de highlighter dus niet valt) kan een bug geslopen zitten immers.

Hydra schreef op woensdag 25 januari 2017 @ 09:20:
Als jij een linter kan vinden die mij verhindert bugs te introduceren dan hoor ik 't graag

Ook een linter doet niet het werk voor je. Met een linter valideer je of de code die jij schrijft zich aan de afgesproken coding standard voldoet of niet. Het gaat niet actief op zoek naar bugs of iets dergelijks. Een andere schrijfwijze is natuurlijk geen bug.

Meer serieus: het is geen 'of' verhaal, het is 'en'. Alle tooling die je gebruikt, je IDE en wat er in je build gebeurt, kan bijdragen aan een betere kwaliteit van je software.

Zeker en ik zal ook niet zeggen dat het niet zo is. Maar (syntax) highlighting en een linter maken niet automatisch code of zo (ik heb een beetje het idee dat er mensen hier zijn die dat wel denken), ze controleren alleen en tot op zekere hoogte kan een linter code ook aanpassen, zodat het voldoet aan de coding standard, maar daar houdt het zo'n beetje op, ze gaan dus niet jouw werk zitten doen.

[ Voor 33% gewijzigd door CH4OS op 25-01-2017 10:17 ]

[Hydra]

CH40S schreef op woensdag 25 januari 2017 @ 09:59:
Zeker en ik zal ook niet zeggen dat het niet zo is. Maar (syntax) highlighting en een linter maken niet automatisch code of zo (ik heb een beetje het idee dat er mensen hier zijn die dat wel denken), ze controleren alleen en tot op zekere hoogte kan een linter code ook aanpassen, zodat het voldoet aan de coding standard, maar daar houdt het zo'n beetje op, ze gaan dus niet jouw werk zitten doen.

Als ik m'n IDE getters en setters laat genereren is 'ie absoluut voor mij 'werk' aan het doen. Dat is nu precies het verschil tussen een echte IDE en een text editor met syntax highlighting.

[CH4OS]

Hydra schreef op woensdag 25 januari 2017 @ 10:25:
Als ik m'n IDE getters en setters laat genereren is 'ie absoluut voor mij 'werk' aan het doen. Dat is nu precies het verschil tussen een echte IDE en een text editor met syntax highlighting.

Maar dat is niet de taak van de (syntax) highlighter of de linter en volgens mij hadden we het over die twee features, niet over de code generation van een IDE.

Als er namelijk in die code generator bugs ontstaan, is het dus logischer om de code generator aan te passen in plaats van elke keer weer achteraf te corrigeren, is het niet? Het is dan ook een beetje raar om een linter te zoeken die voor jou de bugs oplost, zoals je het net althans zei, terwijl de bug dan juist in de code generator zit.

Al hoeft de code generation niet per se vanuit de IDE te komen natuurlijk. Bij bijvoorbeeld Laravel heb je een commandline tool (artisan), waarmee je ook bijvoorbeeld controllers, models en validators etcetera kan laten genereren.

[ Voor 24% gewijzigd door CH4OS op 25-01-2017 10:47 ]

[Hydra]

CH40S schreef op woensdag 25 januari 2017 @ 10:43:
[...]
Maar dat is niet de taak van de (syntax) highlighter of de linter en volgens mij hadden we het over die twee features, niet over de code generation van een IDE.

Euh nee. Ik had het over alle tools.

[Gomez12]

CH40S schreef op woensdag 25 januari 2017 @ 10:43:
[...]
Maar dat is niet de taak van de (syntax) highlighter of de linter en volgens mij hadden we het over die twee features, niet over de code generation van een IDE.

Als er namelijk in die code generator bugs ontstaan, is het dus logischer om de code generator aan te passen in plaats van elke keer weer achteraf te corrigeren, is het niet? Het is dan ook een beetje raar om een linter te zoeken die voor jou de bugs oplost, zoals je het net althans zei, terwijl de bug dan juist in de code generator zit.

Al hoeft de code generation niet per se vanuit de IDE te komen natuurlijk. Bij bijvoorbeeld Laravel heb je een commandline tool (artisan), waarmee je ook bijvoorbeeld controllers, models en validators etcetera kan laten genereren.

Dit is zo ongeveer de fout die de TS ook maakt, benoem alle losse functies en zoek daar een vervanger voor en het zou gelijk moeten zijn.

Alleen je mist dan nog wel de integratie en het gemak en de gebruiksvriendelijkheid waarmee je het in een IDE doet, waardoor je het feitelijk ook echt doet...
Terwijl het met bijv een command line tooltje je het al snel even overslaat als het maar om een piepklein model gaat, dat tik je sneller dan een cmd opstarten, artisan starten en wachten etc.

Een IDE is niet enkel maar simpelweg een verzameling tooltjes random bij elkaar gegooid, het is een geheel...

[CH4OS]

Er zijn in elk geval weinig dingen die Sublime (zij het met plugins) niet zou kunnen ten op zichte van een IDE. Het is tegenwoordig maar net wat de voorkeur geniet. De een blijft liever een IDE gebruiken en de ander kiest liever voor een texteditor. Zeker voor webtalen zoals PHP, Javascript (jQuery), CSS (en LESS / SCSS) om wat voorbeelden te noemen, maakt het zeker niet veel uit. Hoe dit voor andere talen is zoals bijvoorbeeld C++, Java etcetera, daar heb ik geen ervaring mee, dus daar kan ik geen oordeel over vellen hoe dat dan is.

Ik begrijp dan ook even niet wat er 'fout' is, het gaat immers om het doel toch? Of dat met een IDE of een editor als Sublime is, zou echt niets uit mogen maken.

[ Voor 13% gewijzigd door CH4OS op 25-01-2017 12:05 ]

[Kwistnix]

Hydra schreef op woensdag 25 januari 2017 @ 09:20:
Ik ken Dreamweaver zelf niet maar 'hier' is het zo dat de meeste Java devs IntelliJ gebruiken met een paar dino's die nog met Eclipse werken.

Pff, typische IntelliJ elitist

[Richh]

CH40S schreef op woensdag 25 januari 2017 @ 12:04:
Zeker voor webtalen zoals PHP, Javascript (jQuery), CSS (en LESS / SCSS) om wat voorbeelden te noemen, maakt het zeker niet veel uit. Hoe dit voor andere talen is zoals bijvoorbeeld C++, Java etcetera, daar heb ik geen ervaring mee, dus daar kan ik geen oordeel over vellen hoe dat dan is.

Ligt er wel een beetje aan hoe je hier mee om gaat. Als je een PHP framework gebruikt denk ik dat een IDE je best kan helpen, bijvoorbeeld. En LESS/SCSS wil je uiteindelijk ook auto-compilen naar CSS; IDE's hebben daar een standaard plugin voor. Ja oke, Sublime heeft dat ook wel via nuget packages - maar wat is dan nog de hele afkeer die je hebt tegen een IDE? TS noemt specifiek dat hij graag zelf alles schrijft

Kwistnix schreef op woensdag 25 januari 2017 @ 12:09:
[...]

Pff, typische IntelliJ elitist

Liefde voor IntelliJ!

[ Voor 15% gewijzigd door Richh op 25-01-2017 12:17 ]

[CH4OS]

Richh schreef op woensdag 25 januari 2017 @ 12:15:
Ligt er wel een beetje aan hoe je hier mee om gaat. Als je een PHP framework gebruikt denk ik dat een IDE je best kan helpen, bijvoorbeeld. En LESS/SCSS wil je uiteindelijk ook auto-compilen naar CSS; IDE's hebben daar een standaard plugin voor. Ja oke, Sublime heeft dan ook - maar wat is dan nog de hele afkeer die je hebt tegen een IDE?

Ik heb geen afkeer tegen een IDE, dat heb ik ook nergens gezegd. Sterker nog, op mijn werk gebruik ik Zend PDT (op basis van Eclipse), een IDE dus en thuis gebruik ik bij voorkeur Sublime, omdat ik dat gewoonweg veel fijner vind werken voor mijn prive project. Volgens mij had ik dit ook eerder aangegeven in een post in dit topic.

[Richh]

CH40S schreef op woensdag 25 januari 2017 @ 12:18:
[...]
Ik heb geen afkeer tegen een IDE, dat heb ik ook nergens gezegd. Sterker nog, op mijn werk gebruik ik Zend PDT (op basis van Eclipse), een IDE dus en thuis gebruik ik bij voorkeur Sublime, omdat ik dat gewoonweg veel fijner vind werken voor mijn prive project. Volgens mij had ik dit ook eerder aangegeven in een post in dit topic.

Don't get me wrong, het was ook niet tegen jouw gericht Het is TS die een afkeer tegen IDE's lijkt te hebben.

[CH4OS]

Richh schreef op woensdag 25 januari 2017 @ 12:19:
Don't get me wrong, het was ook niet tegen jouw gericht Het is TS die een afkeer tegen IDE's lijkt te hebben.

Ah, omdat je mij citeert en vervolgens 'je' gebruikt in die zin.

[Gomez12]

CH40S schreef op woensdag 25 januari 2017 @ 12:04:
Er zijn in elk geval weinig dingen die Sublime (zij het met plugins) niet zou kunnen ten op zichte van een IDE. Het is tegenwoordig maar net wat de voorkeur geniet.
...
Ik begrijp dan ook even niet wat er 'fout' is, het gaat immers om het doel toch?

Er is niets fout aan totdat het fout gaat zoals bij de TS.

Het is heel simpel, in Sublime werkt het allemaal net even iets anders (ook met plugins etc) waardoor er het gevaar op de loer ligt dat je een andere workflow gaat gebruiken waardoor het niet meer allemaal volgens de standaard gebeurt als het bij jouw bureau vandaan komt.

In principe is daar niets mis mee zolang je het onder controle kan houden en gewoon hetzelfde aflevert als je collega's, dat is ook de reden dat TS het met Sublime mocht proberen in 1e instantie.

Echter als je dan fouten gaat maken, tja, dan zal het veelal toch in 1e instantie zijn : Conformeer maar naar de standaard werkwijze want jouw aparte werkwijze veroorzaakt aparte fouten die we nergens anders zien.
En binnen de standaard werkwijze kunnen we ernaar gaan kijken, maar we gaan er niet naar kijken binnen de werkwijze van 1 devver.

Het is heel simpel : Of TS heeft de meest zeikerige collega's ooit (maar dan had een manager daar wel op ingegrepen, want dan is ook een andere color-scheme bijv uit den boze) want die zeiken over wat er op het scherm van de TS staat terwijl de output 100% gelijk is.
Of de output is niet 100% gelijk en de collega's irriteren zich daaraan.

Al besluit jij om in notepad te gaan werken het moet voor niemand iets uitmaken zolang je maar dezelfde source oplevert binnen grofweg dezelfde tijd.

[CH4OS]

Gomez12 schreef op woensdag 25 januari 2017 @ 12:42:Er is niets fout aan totdat het fout gaat zoals bij de TS.

Het is heel simpel, in Sublime werkt het allemaal net even iets anders (ook met plugins etc) waardoor er het gevaar op de loer ligt dat je een andere workflow gaat gebruiken waardoor het niet meer allemaal volgens de standaard gebeurt als het bij jouw bureau vandaan komt.

In principe is daar niets mis mee zolang je het onder controle kan houden en gewoon hetzelfde aflevert als je collega's, dat is ook de reden dat TS het met Sublime mocht proberen in 1e instantie.

Het gaat pas fout op het moment dat er bijvoorbeeld geen of onduidelijke afspraken zijn over bijvoorbeeld de te gebruiken coding standard. PSR-2 is voor Sublime echt niet anders dan voor Eclipse, NetBeans of welke IDE dan ook. Hoe je je als coder wil gaan houden aan die afspraak, maakt dan toch totaal niets uit?

Echter als je dan fouten gaat maken, tja, dan zal het veelal toch in 1e instantie zijn : Conformeer maar naar de standaard werkwijze want jouw aparte werkwijze veroorzaakt aparte fouten die we nergens anders zien.
En binnen de standaard werkwijze kunnen we ernaar gaan kijken, maar we gaan er niet naar kijken binnen de werkwijze van 1 devver.

In geval van TS gaat het om 3 fouten in 1 jaar tijd...

[ Voor 72% gewijzigd door CH4OS op 25-01-2017 12:48 ]

[Rmg]

CH40S schreef op woensdag 25 januari 2017 @ 12:45:
[...]

In geval van TS gaat het om 3 fouten in 1 jaar tijd...

Dat is de halfbakken uitleg waar TS verder niet op in gaat, nergens een indicatie hoe groot deze fouten nou zijn.

[Marzman]

Rmg schreef op woensdag 25 januari 2017 @ 14:26:
[...]


Dat is de halfbakken uitleg waar TS verder niet op in gaat, nergens een indicatie hoe groot deze fouten nou zijn.

Waarschijnlijk fouten die je in Dreamweaver meteen ziet. Maar een verhaal heeft inderdaad altijd meerdere kanten. Als zijn collega's gaan klagen dat de nieuwe allemaal fouten maakt omdat hij een andere tool gebruikt dan kan zijn baas ook niet veel anders dan zeggen dat TS ook Dreamweaver moet gebruiken.

[Hydra]

Kwistnix schreef op woensdag 25 januari 2017 @ 12:09:
Pff, typische IntelliJ elitist

En terecht!

Rmg schreef op woensdag 25 januari 2017 @ 14:26:
Dat is de halfbakken uitleg waar TS verder niet op in gaat, nergens een indicatie hoe groot deze fouten nou zijn.

Ik hoop bij dit soort topics ook altijd dat de collega ook een account heeft en zijn kant van het verhaal komt doen.

[ Voor 50% gewijzigd door Hydra op 25-01-2017 14:48 ]