Home



Playing around with English to Dutch translation


The following text was produced by an automated English-to-Dutch translator. The original text comes from this article. I thought it might be interesting to see what kinds of results the translator would produce. Needless to say, these things don't produce miracles, and their results are typically kind of rough.

De Bedrijven van de software, saboteren Uw Succes Op lange termijn niet!

Door Jr. van V. Berba Velasco, Ph.D.


In de loop van de jaren, besteedde I.ve heel wat aandacht aan hoe de bedrijven computerprogrammeurs aanwerven.  Tijdens die tijd, merkte I.ve op hoe de managers het huren vaak besluiten nemen die schijnen om steek te houden op korte termijn, maar die in chaos op lange termijn resulteren.  I.ve gezien het soort verwoesting dat dit kan veroorzaken, en hoe verwoestend het aan de toekomst kan zijn company.s.

I.d houd van een paar woorden over dat vandaag te zeggen.

De bedrijven dat I.ve typisch de kwesties van de loonsaandacht zoals de industrieachtergronden, jaren van ervaring, enzovoort waarnam.  Zij willen weten welke soorten projecten de kandidaten aan hebben gewerkt, compilers en werkende systemen they.re vertrouwd waarmee, die de communicatie protocollen en de softwarepakketten they.ve gebruikten, enzovoort.  Velen willen ook van de employee.s de het werkethiek en persoonlijkheid op de hoogte zijn, maar uiteindelijk, koken de het huren besluiten vaak neer aan de employee.s het werkervaring en hoeveel die die de persoon zou vereisen opleidt.

Elk van die zijn belangrijke, zinnige overwegingen.  Aangezien ik deze bedrijven niettemin waarnam, merkte ik dat het grootste deel van them.about 80% of more.paid weinig of geen aandacht aan op of de kandidaat een schone, leesbare programmeringsstijl had.  Zij waren diep betrokken over of de kandidaat de baan kon gedaan krijgen, en didn.t schijnen om veel om of te geven hun software zich gemakkelijk zou kunnen door anderen, jaren onderaan de weg begrijpen en worden gewijzigd.

In wat mate, is dit begrijpelijk.  Toch is het directe doel van de meeste bedrijven werkende producten te ontwikkelen die zij kunnen verkopen.  Wat velen, echter vergeten, is dat zij verondersteld om marathoners, niet sprinters zijn te zijn.  Zij moeten meer in termen van het beŽindigen van de volledige race, en minder denken in termen van het bereiken van overwinningen op korte termijn.

Het verraadt ook een bepaalde naivete over de directe schade die uit slechte programmeringsstijl kan voortvloeien.   Toch zelfs is de beste software zelden vrij van ongedierte.  Een programmeur die schone, zal leesbare software schrijft zijn eigen werk kunnen betrouwbaarder zuiveren dan iemand wie lapwerkcode schrijft.  De laatstgenoemden kunnen moeilijke situaties sneller betwistbaar verstrekken (en zelfs betwistbare that.s!), maar de resultaten zullen unreliable.and wanneer de tijd kort is, that.s een luxe zijn die de bedrijven zich niet kunnen veroorloven.

De werkgevers zouden ook moeten herinneren dat de goede programmeringsstijl niet iets gemakkelijk onderwezen that.s is.  Om het even welke bekwame programmeur kan de werktuigkundigen van van de taalsyntaxis en functie vraag leren; nochtans, iemand wie weinig over het kunstenaarstalent van gestructureerde programmering of juiste objecten richtlijn begrijpt kan waarschijnlijk niet deze dingen op de baan beheersen.  I.ve gezien dit gebeur telkens weer (of eerder, slaag te gebeuren er niet in).  Dit, ondanks de overvloed van boeken en dagboeken die uitvoerig deze kwestie bespreken.

Ik denk ook dat de bedrijven grotere aandacht aan de prospectieve technische het schrijven employee.s vaardigheden zouden moeten besteden; toch kan de externe documentatie (b.v. gebruikershandboeken, ontwerpdocumentatie) aan de houdbaarheid kritiek zijn software.s.  Bovendien, in mijn ervaring, de programmeurs die goed in het Engels schrijven zullen eerder software ook schrijven.  En waarom niet?  De programmeertalen zijn uiteindelijk enkel that.languages.  Iemand wie in het Engels kan goed uitdrukken zal eerder duidelijk en effectief in zijn broncode eveneens communiceren.

Om deze redenen, spoor ik om het even welk bedrijf that.s die een programmeur inhuurt aan om incisive vragen over een applicant.s codagestijl te stellen.  Hoe noemt hij zijn variabelen?  Hoeveel lijnen van code zou een functie moeten bezetten?  Gebruikt hij globale variabelen, en als zo, wanneer?  Welke soorten boeken heeft hij lezen bij de programmering van stijl?  Ideaal gezien, zouden de bedrijven ook om steekproeven van een applicant.s broncode en een technische documentatie moeten vragen, om te verifiŽren dat deze lessen in praktijk worden gebracht.  Dit neemt een weinig extra inspanning, maar het kan een bedrijf helpen vermijden offerend succes op lange termijn omwille van dubieuze aanwinsten op korte termijn.

 

Ongeveer de Auteur:

V. Jr. van Berba Velasco, Ph.D. is een hogere elektro en softwareingenieur in Cellular Technology Ltd (http://www.immunospot.com, http://www.elispot-analyzers.de, http://www.elispot.cn, http://www.elispot.co.jp) waar hij met grote trots dient. Hij heeft gezien hoe de juiste aandacht aan softwarebruikbaarheid, houdbaarheid en elegantie het verschil tussen middelmatige producten en grote degenen kan spellen.




Index to the various translations of this article

Articles and Stuff