28
loading...
3.5 Years as a Front-end Engineer - Things I Learn and What Next?
Originally posted on my blog.
Every once in a while, we software engineers/developers face a moment where we have to slow down our thought and take time to rethink, reshape, and eventually replan our careers. Have we made our career so far on the "wise" path? Did our progression was the best decision for our individual development?
So far in my software development career, I see differently now about "promotion." Frankly, I was even scared of it. And I am not pretending about it. Everything is now inside the merit-based "scope." For illustration, was I deserve to receive that promotion? Was it based on my skills or just my experience (how long I've been) at the company?
But in reality, you can't decide your fate about everything, and it's all right. I will never be ready for everything. Our career growth is no exception.
So, as my attempt to maintain my expertise (and improve it) and be ready for everything in the future. I've read some books, digesting some tutorials, creating courses, launched a product, and now writing a blog. So in this article, I'll share my learning so far.
The truth is, I've never been a software architect. My three and a half years of career as a software developer, mainly as a developer. Wait, what? Did I indicate that software architect and software developer is different? Yes, I did. According to this book: Fundamentals of Software Architecture by Mark Richards and Neal Ford.
The mental difference is based on "How to see at some point of view." But before I dive deeper into that, I need to explain why I think this is such an excellent book to read and to be prepared for the next challenge. As I am reading this book, I reach what I felt was the correct path on my own. In the end, I will go ahead with what I do now. As my career path grows, I will have little time to do actual coding tasks and be involved more in decision-making.
My takeaways from learning this book will not incorporate all of the book's contents. It only satisfies about 3-6% of the book's overall contexts. So everyone still needs to absorb the book to get all the meat.
My key takeaways from the book are from Chapter 2: Architectural Thinking. During my entire career, when it comes to picking a technology stack (tool, library, or framework), I begin with the benefits of the tech choices. But I never analyzed the trade-offs. Talking about architectural thinking, I need to look at the help of a given solution (or a stack) and explore the negatives, or exchanges, associated with a solution.
I'll take an example from Lee Robinson's tweet. He's the Head of DevRel at Vercel, the company behind creating one of the most delicate React frameworks: Next.js. Still, regardless of how convenient it is to use Next.js, it also comes with negatives or trade-offs.
Deciding to use the frameworks has to come after deliberation of the trade-offs. For occurrence, is our team is already proficient with another language/framework and doesn't want to switch? Is the web products we want to build will need a lot of JavaScript to run? Or maybe our team is not a React person and more of a Vue person?
Before deciding on the stack, addressing those trade-offs makes the difference between (most of) developer thinks vs. software architect (should) thinks. And finally, the actual answer for those questions is always, "It depends." You can't Google it. And the final decision must be taken after we proceed with solutions we genuinely evaluated based on our concerns. It can depend on the business needs, environment, people, and a host of other factors.
I've talked about pondering trade-offs before. But this part is the hardest (at least for me personally). When I need to choose when to add stuff, I must know, maintain expertise of things I already know, and knowing what I don't know. It requires very effective time and energy management.
Someone says that a good place to learn to program is on the job. I've learned so much on the job, but I also learn so little on the job. Don't get me wrong, I fully agree with learning on the job. Because I feel know how to do a lot on the job, to an extent. When I hit that wall, it's hard to get around. There needs to be time to learn other than just on the work I am currently doing.
So I've spent more time learning outside my work. I am maintaining my expertise on something I already know (like taking the Epic React course by Kent C. Dodds) and expanding my expertise for something I don't know (like discovering Rust). But I feel like it is something that I can't do forever. Let me clarify.
My work as a software developer required me to have a significant technical depth to perform my job. Means I need to stack up "stuff I know." But that is not enough; I also need to maintain it. I've been doing web development work with React since 2017. I can say I know a lot about it. But it's 2021 now, my React knowledge is quite obsolete right now if I'm not maintaining and upgrading my React stuff these days. That's why I called it keeping the "stuff I know" or Technical Depth.
Fast forward to the future, and by recognizing other's personal experiences, Technical Depth simply is not enough. I am required to have broad knowledge about other technical stuff outside my current expertise. Because the kind of information a tech person should have value differs within career stages. It is more in the "stuff I know I don't know" field. I've heard the good news about Rust; it is syntactically similar to C++ but with many improvements. The development was even supported by some notable names, including Brendan Eich (the creator of JavaScript). I can't code the language yet. But I know Rust will solve particular problems in a way JavaScript can't.
If a developer transitions into the architect or decision-making role (like a lead developer). A large part of the value of that role is a broad understanding of technology and how to use it to solve particular problems. It is more advantageous to know that three solutions exist for a specific situation than to have singular expertise in only one.
When my career has come to more decision-making, it has to either pursue Depth or Breadth of technical expertise. A broad understanding of a wide variety of solutions is valuable. Hence it has to be Technical Breadth with more weight to choose from rather than Technical Depth.
I've said it before that it's the most challenging part for me. Choosing one of the options rather than both. The skills I've already acquired until today are "hard-won." Either it hard for me to learn, or it was expensive. Someday I will "say goodbye" to all of them. Only taking fundamental skills with me to wade through the next stage of my career.
In my earlier days as a software developer, I didn't value time like I do today. I didn't even know the difference between Productive and Busy. At the end of every workday, I'll feel satisfied when I busy all day. It feels good to be busy back then.
Turns out they are different. You can be busy without being productive. But you can be effective and produce a lot of value without being gaudy at all. It was felt mystic when I knew it, "Do more with less time?". Since that day, I decide to persevere productivity more.
But it wasn't that easy. It requires a lot of habits to fix to achieve better productivity. My sleep habits weren't that good. Turns out, everything has come down to this. Improving my sleep habits opens many possibilities for better productivity.
In my earlier days, I spent all working hours just to finish all the tasks on my full-time job. My skills and speed to complete all tasks in a day weren't that good. It has to do something with my learning habits. Because every day after work, I always feel exhausted. But I also feel delighted with what I did every day. No energy left to do extra Coding or learning stuff. But that doesn't mean I will sleep right away; instead, I was playing games. Eventually, I had a lot of late nights sleep cycles.
When I finally fix my sleeping habits. I have more energy to do more. I started to do part-time jobs, creating content and doing a business that gives me passive income. It's not about hustling; it just a way to avoid wasting my precious time. When I can get more done, I'll have more time to learn, be better at my job, creating value in my business, and earn more money to provide for my family.
It's been a very fruitful moment of my life. I started in engineering career as a Coding Bootcamp graduate. It was a very fulfilled experience to have been able to have a time in my life as a software engineer. Three and a half years (and counting) to do the work as a front-end engineer pave the way to various possibilities, meet new friends, create more values, and provide my family better. Even before being a front-end engineer, I thought I will never have a spouse.
I should have also written a blog to summarizes my life pre-engineering career. So I can finally say thank you to all persons who helped me have a better life by accepting me as an engineer. If you want to read it, stay tuned for further updates!
28