Full-Stack Engineer

I am a full-stack engineer because I believe in the value of the vertical slice. By putting user value as the top priority, it becomes necessary for an engineer to be able to work in the whole stack of the application, to successfully deliver a feature that provides value.

I don’t buy in to critiques of full-stack engineers that say “you can never be full stack, because you don’t touch [platforms/hardware/insert-your-own-here].”

For me, the meaning of full-stack is that I can deliver a slice of user value, to whatever extent and whatever code that means I need. Most commonly, that means UX design, frontend code, backend API code, and databases or integrations. It means I can handle cloud platforms for deploying if needed. But it also means I can black-box away things that I don’t need to know (like hardware optimizations) because often, I can use tools that manage that for me, so I can focus on user value.

To me, full-stack engineer also connects to my ability in learn to learn - I don’t hyperspecialize in browsers, or databases, or anything. Whatever the user problem is, I can learn the technologies (frontend, backend, database, or anything else) needed to solve that problem.

To me, a full-stack engineer is a problem-solving engineer.

Here’s a non-exhaustive list of the technology stacks I have experience with:

Frontend

languages: #javascript #typescript frameworks: #react #angular #vuejs #flask tools: #sass #webpack

Backend

languages: #java #kotlin #dotnet #python #javascript #typescript frameworks: #spring #express tools: #maven #gradle APIs: #REST #SOAP #GraphQL

Testing

unit: #junit #jest #jasmine #mocha #rspec integration: #spring-cloud-contract #pact end-to-end: #cypress #testcafe

Storage

#mysql #postgresql #elasticsearch #mongodb #redis

Deploying

#cloudfoundry #aws #kubernetes #googleappengine #heroku #akamai