Lang geleden programmeerde ik voor mijn loon. Enfin ja, ik zeg “programmeren”, ik bedoel eigenlijk: ik defelde maar een beetje aan, en ik stampte en duwde aan code tot er iets uitkwam.

Gaandeweg heb ik wel geleerd hoe het eigenlijk zou moeten, maar tegen dat ik dat aan het leren was, was mijn werk niet meer het programmeren zelf maar eerder andere mensen doen programmeren.

En toen ging ik helemaal een andere richting uit, en was “programmeren” iets dat ik hier en daar eens deed tussendoor, maar nooit voor het werk. Soms eens een scriptje ja, maar echt ontwikkelen: neen. Er zijn mensen die daarvoor gestudeerd hebben, en die dat duizend keer beter dan mij kunnen.

Ik ben al content dat ik begrijp waar het over gaat als er over unit testing en decorators en scalars gaat, dat dat geen testers van airconditioning en binnenhuisarchitecten en muurklimmers zijn. En ik ben al content als ik code kan lezen en mij kan verplaatsen in de nodige manier van denken.

developers

Maar zeer soms kan ik geen neen zeggen tegen een project, en dan komt het er toch nog eens van dat ik iets méér dan een klein scriptje links of rechts doe.

Gelijk deze week: Django. The web framework for perfectionists with deadlines, weetwel. Bijzonder leutig, dat had ik al gezegd, en met een beetje Google en Stack Overflow is alles op te lossen, als er niet van al te dichtbij naar de properteid van de code moet gekeken worden.

Om nog niet te spreken van de properteid van de werkmethode. En ‘t is niet dat ik niet weet hoe het zou moeten hé.

De theorie: lokaal ontwikkelen, werken met een lokale git reposity, lokaal testen in development, om de zoveel tijd eens een stuk pushen naar github, en als een groot stuk af is, dan pas deployen naar de productieserver.

Helaas.

De praktijk: files editeren op mijn computer (van thuis of van het werk, afhankelijk of ik aan mijn bureau in de living zit of niet), en zo ongeveer alles committen en pushen naar github, en dan op de server pullen om daar te testen.

Ja, op de live versie. Met de live data. En voor ge mij doodschiet dat ik op live data werk: ge moet er niet mee inzitten, want de data leeft in een sqlite-bestand, dat ik gewoon mee naar de repository stuur.

Ja, nu moogt ge mij doodschieten. (Alhoewel: ik heb wel degelijk een betalende github-account, dat ik die data van de rest van de wereld kan weghouden.)

En nee, ‘t is niet proper, op die manier werken. En mijn commitgeschiedenis is dan ook navenant:

  • remove unnecessary donotwant
  • verdwijn!
  • ga weg!
  • donotwant nu helemaal weg, oef
  • job pools added
  • nieuwe db tralala
  • jobpool aangepast, hopelijk
  • sorl weg gvd vuilaard waarom bleef dat staan?
  • jobs per poule ipv per eigen voorkeur
  • taalkennis Nederlands apart toegevoegd
  • max length not needed, pf, serieus gast
  • db hoezee
  • opmerkingen vergeten kak
  • kennis e.d. in database gestoken
  • allerlei taalrelated stuff toegevoegd aan admin en fiche
  • eens kijken of dit iets doet want het werkte niet
  • dit zou toch moeten werken, denk ik
  • poging drie talen en eigen/assessment split
  • poging zoveel talenstuff waarom zie ik het niet aaargh
  • ‘t is officieel: ik ben een idioot
  • we hebben geen switch! fuck it! we’ll do it without labels!
  • time to call it a night, peisk

Of nonsens zoals dit:

Capture

Jaja, het glamoureuze leven van een has-been programmeur die nog net genoeg weet om een beetje zijn plan te trekken.



Reacties

3 reacties op “Ik zou niet welkom zijn op het werk met zo’n manier van werken”

  1. Dat is allemaal best te rechtvaardigen. SQLite in productie draaien wordt vrij snel een probleem, maar live editen op de server, waarom niet… er zijn situaties waar dat de beste oplossing kan zijn.

    Dat lijkt een beetje op hoe wij projecten ontwikkelden op webfaction. Het grote probleem is dat webdesigners weinig trek hebben om lokaal een ontwikkelomgeving te installeren (nog steeds niet denk ik) maar ze wel front-end code moeten bouwen op een werkende site. Onze oplossing toen was een django site te hebben op webfaction waar de webdesigner templates en assets live kon editen met een SFTP editor. Dat was voor hem de snelste manier om te kunnen refreshen en resultaat te kunnen zien. Ik logte dan eens in de zoveel tijd in met SSH en checkte zijn werk in in github.

    1. Ik ben het ondertussen beu geworden, en ik heb alsnog een test/stage-omgeving lokaal gezet. 🙂

      SQLite zal geen enorm probleem zijn, denk ik: het is een applicatie die letterlijk door één of twee personen zal gebruikt worden.