I have spent a lot of time commuting to and from school/work this year--it is tiring and draining. Although it sounds like hell, commuting has one advantage: idle time. More time to reflect and listen to your thoughts. So yeah, I have been thinking and listening to my thoughts--daydreaming.

"About what?" you might say—a lot of things. However, engineering is today's focus—my journey before this paper and my ideals hereon. One question has been hunting my mind for the last two or three months -- How does one become a top 1% level engineer? I understand this isn't everyone's call, and that's okay. However, when it comes to me, I am very competitive. And I want to find out how I can reach the pinnacle of engineering.

First, let's talk about what will not help you reach this potential--the programming language you are using. Often you hear people, especially juniors asking, "What programming language should I learn"? or "Which framework is this and that." You need to know something critical--nobody cares which language, tool, or technology you use as long as you get the job done. Do not give in to peer pressure and the new shiny tool in the market. Choose a path and stick to it; you will get more flexibility to change technology and play around with tools when you reach intermediate levels. Just don't be the stray dog!

Now back to it, the secret sauce! But before we get there, I have a short story I read from a random person on Reddit and think it's worth sharing. The story essentially boils down to one question. Consider the dynamics of construction workers in your community, city, or state and reflect on something. "Would you like to be the local handyman who gets called for quick fixes and construction tasks here and there or the architect and engineer who designs and builds complex structures and skyscrapers?". If your answer was Architect and Engineer, the rest of this paper is for you.

There is more than one way to make it to the top. However, there is only one way to the fundamentals--we won't talk about fundamentals. Becoming a top 1% level software engineer requires combining technical skills, a strong work ethic, and the ability to learn and adapt to new technologies continuously. However, this is usually tricky because some things are abstract, and you might lose your head in between if you try keeping track of all the moving pieces. Because let's be honest, you cannot acquire all technical skills there are, nor can you quantitatively track your work ethic or how you are keeping up with new tech when a new one is coming out every month.

Luckily there is an alternative to all of these shenanigans--one source of truth for your progress across multiple clusters of your engineering journey.

Projects. Yeah, you heard me right!

Moving from whatever approach you use to a "Project-based" approach is the way to go if you want to embark on the 1% journey. From my experience, I have seen people "label" themselves many things--Web Developer, iOS Developer, Python, RoR--you name it--developer. Using labels is acceptable; however, it's a limiting factor on this journey. What matters is problem-solving, not the language, tools, or technologies you use. You should use tools and language as a side effect--don't make it your main focus; you will lose!

I have been using this approach this year, and it works. Let me tell you how it works. Essentially, you look around for problems to solve, ask your friends, family, and colleagues, or be observant; you can go big or start small. It does not matter. Once you have these problems, let them dictate the tools, language, and technologies--more time for you to focus on abstracts and the critical part that people often forget: System Design and Architecture.

See, this process already sends you one layer of complexity down and gives you ownership over the whole engineering process. From the rough idea to Stakeholders Analysis, UI/UX Research, System Design, and Architecture, the build and launch, to name a few—the kind of exposure you need to reach your ideal.

You get exposure to all engineering layers and the chance to use and see tradeoffs between languages and tools, knowing when to use which and where. You get to know things like, even though Flutter is hybrid and lets you write code once and run everywhere; you would not choose it to build you a scalable web application that needs speed. Or know when to use Native Infrastructure with Swift or Android in specific scenarios. You can only see this kind of detail using this engineering approach. Otherwise, you'll be just coding like an IDIOT--everyone can do that!

I am taking it, and it is working. You should try and see for yourself.

For you wondering, yes, you also get to hone your intrapersonal skills, communication, time management, stress management, work under pressure, and more. Once you join a team or are senior enough to manage a team, you have a good package and understanding of each stage of product engineering. The designer or that one engineer won't bullshit you about things--you could probably do some of their jobs better than them.

YAFOY!