Hi! I’m Alisson, 32, A (full-stack?) Engineer currently working in Tokyo, Japan.
If you’re an Engineer in a foreign country trying to overcome your Impostor Syndrome like I am, this blog is for you.
The question mark is there because, well, there’s no real certificate or nameplate that gives you the “full stack Engineer” status; you just spend a lot of time doing a crazy range of work and you become one.
I’ve checked out “crazy range of work” off my list, but still, everyday at work I’m finding out there’s something else I with I had studied earlier, so that self-doubt is quite persistent. Self-doubt is the one thing you don’t want to hold on to as an Engineer, though. I’m sure the following thoughts are quite common (and I felt them for a long time, and I see them in Junior Engineers around me all the time):
- I have no idea why the API and infrastructure is set up like this, but it’s not my area of expertise so I can’t really ask the other Engineers for anything different.
- I really wish this information was all in the wiki / (and at the same time) I’m not confident enough to write a wiki post.
I understand where this comes from and it’s okay to feel those feelings: a lot of us are built to feel unconfident without enough knowledge. However, the results of this line of thought are always sad for everyone involved, because lack of confidence leads to poor information sharing and miscommunication issues; miscommunication makes project members not have their goals aligned, and that’s what makes most projects in most companies drag out and feel like hell.
Interestingly enough, on the other hand, even if the goals are hard and the schedule is tight, when the team members understand and respect each other, all of that becomes bearable.
So hear me out: to be understood and respected by others, all you need is more confidence, no matter what level of knowledge you’re at. How do we tackle this problem then? We post.
You haven’t learned anything properly unless you’ve succeeded at explaining it with words at least once
Learning a bit from the outstanding Engineers I’ve met since I joined my current company, I’ve come to realize we need an output for the things we learn daily. Not to show the world, but for self-assurance. I have a lot of knowledge from the past years in my career, but since “it’s all just in my head”, every answer I give a co-worker when they’re facing a tech problem feels great when I’m actually right, but “something I wish I had written somewhere for proof”. And let’s be honest: “I have this post about when I faced the exact same problem. I can send you that” sounds more reliable than “if I remember correctly, maybe this would work, I don’t know”.
Thus, this series of posts entitled “The Road To Full Stack” will register the steps I’m taking to call myself a Full-Stack Engineer – without a question mark! – and to prove to you and I that:
- Blog posts don’t need to be perfect; writing them is already a great step to growth. People will come at you at the comments for your “messy code” or “tackling the problem with the wrong approach”, even your English. Take the advice from the nice ones, ignore and block the jerks. It’s that simple.
- Everything you learn about fields outside your area of expertise, no matter how little, will make for more pleasant conversations with other Engineers and, therefore, more pleasant work experiences.
Now that we’ve tacked the mindset we need to tackle the rest of this series (and I’m very positive towards talking about mental health openly), let’s talk about the order I will learn and post things.
Leave the fun for last
In a series of posts about full stack, It would probably be more fun to start with some aggressive coding and deploy an app as fast as possible. If that’s what you were looking for, this is not the blog for you. However, if you’re anxious like me and you like to start with building blocks before trying complex structures, the order in which I will write the posts will be the following:
- Managing infrastructure with AWS CDK
- Choosing your frameworks and languages
- Coding the frontend and why learning one design tool is important
- Coding the backend
- Extra: how did I organize the concept with Figma and Notion
as you can see, this series will be DECREASING in boredom and difficulty as we move forward.
This comes from my concern with developing anything without a clear vision and proper planning. It is a concern (almost a deep fear, really) that I’ve developed over the past four (Japanese) companies I’ve worked at, where it seems every new product development lifecycle seems to fall into the same pattern:
- Big bosses want something that makes money and they want it fast.
- The ratio of highly-skilled, highly-confident Engineers with a little extra time to newcomer Engineers is about 1:4.
- Big bosses build a team of ratio 1:4. (Because there are other projects that give more immediate profit and those need the highly-skilled staff)
- The 20% part of the team that has all the necessary knowledge builds everything for the dev team; databases, networking settings, app deployment infrastructure, app development environment with selected frameworks and packages. The rest is assigned coding-only tasks.
- The 80% do what they can with the resources they have, but because of time constraints, it’s not easy to get enough time from the 20% to get concepts explained properly and grow as an Engineer. Most of the code written from then is therefore almost entirely copy-pasted from Google (now ChatGPT, which is at least less worse).
- Because the big bosses still want money, eventually the 20% are assigned to other projects (that give more immediate profit and need the highly-skilled staff). No documentation was left behind.
- The remaining 80% know nothing about why the current infrastructure, frameworks and packages were selected.
- Every task from then on that require a bit of change to the Product Specifications takes days, because everyone is dancing in the dark.
- Test phase never starts; we never get to beta; we never sell the product. Delivery delayed.
- Big bosses not happy.
You can tell from the list that I’m skeptical about product development with a badly formed team from the start, but honestly that’s not the point of this post. Circling back to the thoughts I expressed in the beginning, if we were all part of the 20% to begin with wouldn’t development just simply be less stressful?
If you want to follow me on my journey to understand what exactly is dangerous about my current team and how can I become a better Engineer to become part of the 20%, I hope you keep reading the series.
Nice to meet you and let’s start!