Een developer die Java kan… maar ook C#, Ruby, etc…

Als iemand vraagt of ik een “Java developer” ben dan antwoord ik vaak:

Ik ben een developer die Java kan…

(maar ik kan ook C# of Javascript of Ruby…)

Dit zeg ik niet om flauw te doen maar om aan te geven dat het kennen van de syntax van een programmeertaal weinig van doen heeft met het bouwen van software.

Natuurlijk, je moet de syntax kennen. Maar daarna begint het pas. Syntax is zoals grammatica. Je zet een haakje hier, keyword daar, if-statement hier (of switch), of een lus daar.

Zodra je logisch kunt nadenken en ervaring hebt in een 3e generatie taal dan is het leren van een nieuwe (3e generatie) taal vaak niet meer zo moeilijk.

Let wel, het leren van een nieuw paradigma (Functioneel Programmeren vs Object Oriented of Procedureel, etc) kost wel tijd. Ook het in-depth leren van frameworks kost tijd. De vraag rijst of dat je moet tegenhouden om goede mensen aan te nemen.

De waarde van parate kennis (mbt frameworks en talen) is minder van belang met dingen als Google en Stackoverflow. Deze websites zijn niet voor niets populair.

Betekent dit dat je dan maar alles kan opzoeken en dat elke developer zo een beetje alles maar kan?

Nou nee… ik zou voorzichtig zijn met een doorgewinterde webapp developer inhuren om een mobiele app te laten bouwen. Wel kun je een webapp developer laten meedraaien in een dergelijk team, diegene zal het waarschijnlijk vrij snel oppakken.

Maar, zolang we over dezelfde soort applicaties blijven praten, dan is het risico mijn inziens goed te overzien.

Laten we een webapplicatie nemen. Deze kent vaak een aantal ‘bouwblokken’, hier is een (niet volledig) lijstje:

  • een persistence laag (data moet ergens opgeslagen worden)
  • clients die met 3rd parties communiceren
  • routing, actions, controllers (MVC)
  • een API voor 3rd parties (JSON, SOAP, XML-RPC) aanbieden (middleware?)
  • een frontend API (JSON, SOAP, XML-RPC)
  • HTML/CSS voorkant (al dan niet als aparte app of vanuit de backend gegenereerd)

Je ziet in dit lijstje geen framework staan. Wat je wel ziet staan zijn protocollen en design patterns.

Als je een Javaan pakt die gewend is met het Spring Framework te werken en met build tooling als Gradle of Maven. Dan zal diegene vrij snel up to speed zijn in een .Net omgeving. Zeker als je een bestaand team hebt met bestaande codebase. De patronen blijven hetzelfde, hoe je het opschrijft is hooguit anders. Spring heet nu ASP .NET. Gradle heet nu misschien MSBuild. Maar een JSON koppeling blijft een JSON koppeling. Controllers blijven Controllers. Routing blijft routing. De regels van het spel zijn hetzelfde. Hoe je ze opschrijft is veranderd.

Je zult misschien denken, leuk en aardig, maar hoe snel is deze Javaan dan ‘productief’ in het .Net wereldje? Mijn ervaring is dat dit niet heel erg veel uitmaakt t.o.v. iemand die al in .Net heeft gewerkt en ook een nieuw project moet inregelen op zijn machine. Dat is overigens niet alleen mijn ervaring maar ook die van mijn klanten die mij inhuurde om een .Net project te doen – terwijl mijn ervaring tot dan toe Java en Ruby was.

Wat wel gezegd moet worden is dat de ervaren .Net developer een voorsprong heeft in parate kennis. De tooling eromheen, puur ervaring over eigenaardigheden van de taal of frameworks. Voor deze specifieke zaken zal de ervaren developer altijd ‘winnen’.

De vraag is echter, hoe vaak heb jij als onderneming te maken met deze specifieke zaken en wanneer ben je ‘gewoon bezig met features bouwen’?

Mijn ervaring is dat de noodzaak om deze ‘expertise’ vaak minder hoog is dan de noodzaak om ‘gewoon goede vakmensen’ in te schakelen en een klus te klaren. Goede developers, ongeacht de tech-stack, kunnen een hoop waarde leveren meteen vanaf het begin.

Ik denk dat developers die met verschillende stacks hebben gewerkt van meer waarde zijn.

Dit komt doordat ze de verschillende aanpakken van frameworks en talen hebben ervaren. Je krijgt met elke nieuwe Stack letterlijk een ander perspectief hoe je een vraagstuk oplost (lees, webapp bouwt).

Vergelijk bijvoorbeeld hoe Ruby On Rails versus Spring werkt, als je daarna met het Play Framework gaat spelen dan herken je opeens een hoop dingen vanuit Rails. Mijn visie is dat hoe meer ervaring je opdoet over andere frameworks en talen hoe beter je zal performen (in de basis).

Conclusie?

Het komt neer op wat je wilt. Wat wil jij, als organisatie, bereiken? Wat voor soort mensen heb je werkelijk nodig?

Als je een webapplicatie bouwt, zoek dan mensen die ervaring hebben met webapplicaties bouwen

Kennen ze ook de Stack die jij gebruikt? Mooi! Niet? Benader ze toch!

Ofwel, moet het een “Java developer” zijn of “een developer die Java kan”?