Using var hides the true types of your identifiers. Having to know every type that you pass on parameters, methods, helpers, etc., is really a good practice. It’s because we have good IDEs now that you can’t appreciate this for now, but having to code on an online compiler without that static typing and those compilation errors will make you realize to write your types explicitly. You will be exposed to types that are not usual on your code writing. Types like IQueryable that are often abstracted on your var keyword when you write your queries using LINQ. Of course, there is an exception dealing with anonymous types, but I hope you do get the point.

2.) Know LINQ — The Bread and Butter of C

You can’t code in C# without encountering LINQ. Whether you’re querying a collection, filtering data from a database, or transforming. You will spend a lot of time writing LINQ, and it’s beautiful, isn’t it? It’s like a chained poetry. It’s expressive. One thing I stumbled upon is this article/blog. https://steven-giesel.com/blogPost/00443661-f75b-4694-852b-175b4a10d6c4/linq-mindmap-net-10-edition He builds a LINQ Mindmap to really embed that LINQ knowledge in yourself.

3.) SQL before ORM

Having a good understanding of SQL will make you understand your ORM better. Yes, everyone will start and jump at using Entity Framework Core simply because there are a lot of resources there and .NET dev influencers that are using it. Having a grasp on SQL will make you write queries better at LINQ + EF Core. You will understand how your ORM behaves.

4.) Know your heroes

Know your heroes, just like the old saying, If you wish to be successful in some field, you gotta know the people that you consider successful in that field. Following successful/famous devs, like the ones who created your favorite library. Oftentimes, they have blogs and accounts on X (Twitter) you will be updated on their projects and field of study. It’s a good investment of your time considering how much technical debt you need to study in order to somehow lessen that gap to your heroes. And by technical debt, I mean the knowledge that you need to amass in order to be somehow considered decent.

5. Take an AI Detox

Yes, having assisted programming is the best feeling; just by clicking a tab will trigger Co-Pilot auto suggestions on the code you are writing. Don’t push code that you barely understand. A good programmer can explain the code that he/she has written line by line.

6. Know Thy Compiler

This will be your edge on AI. We are now in the age of AI, although the quality of the devs is getting lower because of trading productivity for learning. But this is our time to be better. Knowing IL code is a must in this age of AI. Having that confidence that you know what your compiler is implicitly doing. There are a lot of extensions and IDEs that are offering viewers, trust me, it will be worth it.

7. Skip Architecture (For Now)

Stop arguing about architecture; there will always be a tradeoff. Skip that for now, accept that you are not a seasoned developer. Avoid worrying about architecture for now and just start building fundamentals - I don’t know why .NET devs are obsessed with architecture. As someone who is new, you just need to build your fundamentals and know your tools pretty well, like really well.

8. Leetcode, but With Purpose

Solve LeetCode problems , If you’re not comfortable doing LeetCode problems and you argue that you would rather build a project, it means that you are not a decent C# dev. Leetcode but with purpose. You can start doing LeetCode in order to practice and build your LINQ skills. Just be comfortable writing LINQ with C#.

9. Blog it or Lose it

I can’t stress this enough: every developer should have a digital repository for their coding career. Whether it’s a blog, a private Notion page, a YouTube channel, a GitHub repo collection, or even voice memos, it doesn’t matter. What matters is that you start recording what you learn, what you build, and how you solve things. Not all things you read will stick. You will forget it. So create that digital repository. Your future self will thank you for starting this.

10. Be honest with yourself, you know that you don’t know a lot

The first step in learning is accepting that you don’t know a lot.

Very straightforward, don’t pretend that you understand the code that your colleague wrote. You can explain why the senior wrote that snippet. Don’t run from ignorance, tackle it!

FullStack as a Trap: A Reflection

In my opinion being a full-stack is a trap for someone who is new on the software engineering field.

I would rather be a junior on a specific end (front-end or back-end) rather than be a full-stack developer who works at the client side and server side but doesn’t have a deep understanding on what he / she is doing.

Yes, fullstack is a lucrative career. It looks great on a résumé and often comes with appealing salaries. But in my view, being a specialist will be far more rewarding in the long run.

It healed my impostor syndrome when I just focused on back-end. Having to understand your code line by line and not prompting your way to production will surely make your confidence grow. Also by going back to fundamentals and not skimming through the hot technologies, Please.

The Industry Problem — and the root of your impostor syndrome

Forgive me for what I’m going to say but, I noticed that there are just people in the industry that are guilty of this. We call ourselves “fullstack,” but what we’re really doing is building on top of frameworks without truly understanding the foundations beneath them. Of course you will feel a fraud, cause you don’t know how that x library works!

I think this the root of impostor syndrome, atleast on my own experience. Not having to question, how did that happen? Like example when you are using a library , a back-end library by just injecting that piece of code that x feature is working. Question it, like the famous Automapper library on the .NET community how did it map your entities to your DTO? The answer is reflection in c#. I’m not saying that you should really understand it to the point you can roll your own libraries. But having a grasp on those tools will surely make you a better software craftsman.

The Learning Problem

How can you learn or say that you are fluent in a technology when every year the knowledge that you need to partake increments? It’s impossible to learn everything in and remain good or relevant in an industry like tech, but having a deep understanding and a good fundamentals will surely make you still relevant for 1-3 years in a particular stack. That’s why full-stack isn’t for the new ones, It’s for the much seasoned developers who already have an in-depth understanding of one area, who are already experienced on more projects.

So here is my take, If you are lucky enough to land a role that let’s you dedicate yourself to one end. You may escape the paradox that ensnares a lot of new developers. You might be much more closer to the stillness, on the state of stillness that you are somewhat comfortable / decent on utilizing your stack.

“Now will you choose to learn broadly and risk knowing shallowly, or learn deeply and risk irrelevance?”