June 18, 2019 ~ 3 min read

Fullstack software engineer vs being a software engineer


Today marks day 2 as a fullstack software engineer at Mount Sinai NYC. I've joined a pretty early stage project that aims to become the Slack-Uber-WhatsApp-like communication platform for healthcare. We have a startup feel but with the benefits of an enterprise backing us - pretty sweet.

I won't be speaking much of the project itself but I will share how I feel as a "fullstack" software engineer and what I see myself learning and doing. And just also where I am clearly lacking in skill and experience.

Now that I've gained the rather flimsy but venerable title of "fullstack" software engineer, I realized that it means little. LOL. All this means is that I'm allowed and encouraged to push code in Golang in the back or Javascript in the front. It doesn't mean anything if you don't understand the many moving parts necessary to build a software system. I'll go into job marketability later.

To build a system that caters to millions and billions of people requires a large breadth of knowledge. Thus why we work in teams; everyone can complement one another's lacking spots. Take for example Mount Sinai's first MVP: a chatbot underneath the hood.

To build a chatbot and integrate it into Mount Sinai's ecosystem, you need to understand all the moving parts: i.e., authentication of users from patients to whatever staff, how and who the chatbot connects to within our ecosystem, and also internationalizing our product for our multilingual user-base. Breaking down each of these further will too spin up numerous other questions.

So in short, it's not knowing about the actual technology itself, but understanding how it all comes together.

For myself as a fullstack software engineer, I have to very much understand system design, and not just in terms of scalability and reliability, but integrations into our existing technologies. While I do know how to build a standalone application with Go and Javascript, I don't know how to build a platform that caters to many real users. Moving forward, I plan on becoming flexible enough to not just write Go but understand the core concepts of building a reliable backend. The language doesn't matter. As for the front end, I also intend to stay up-to-date with the latest trends in my particular sphere, namely web performance optimizations and React.

Though there's still two things to touch upon: job marketability and fun.

We as developers want to have fun. It only makes our lives more enjoyable when we get to work with new toys, and honestly, be cool among our peers. Using a particular tech and sharing about it is like buying new shoes and hoping our eagle-eyed friends will notice. You're hoping someone notices and compliments you. Otherwise it doesn't really matter. Fortunately I like Go. (But OCaml!! and Reason!!).

Then there's marketability. The current job market favors generalists, especially among startups and even the Big N tech companies. But do I think I'm personally valued higher now that my title is "fullstack?" It's a double-edged sword. I feel higher expectations. Expectations that I know certain patterns and best pratices at both ends of the technical spectrum.

Instead of using the term "spectrum," it may be more apt to illustrate our skills as a hexagon, or whatever n-polygon, akin to the charts in racing and fighting games: Speed, Power, Recovery, Skills, Magic.

Thus, my conclusion is that people should strive to be software engineers rather than fullstack. An engineer connotes much more experience and understanding than someone that understands how to write Javascript for both web and server-side.