As someone fresh out of university aspiring to become a software engineer, I often felt like I don't belong in this field. There's always something that I don't understand, and the stuff that I thought I did, turns out I didn't understand deep enough. I had the extreme case of "imposter syndrome". Thus, I became determined to at least try to not feel that way. As a software engineer, there are plenty of activities that you'll do, but one in particular is what everyone associates us with: coding. I figured if I had to relieve my sense of "impostor syndrome", my focus had to revolve around that.
Initially, I felt like every line of code I wrote was slop and the programs I produced was unworthy of production environments. I lacked confidence. However, I've felt a bit better as of recent and by sharing what I've learned, I hope I can help you relieve that feeling too.
Before we talk about syntax, we have to talk about the Dunning-Kruger Effect. When you first start, it’s easy to think you understand everything because you don't yet know how much you don't know. To grow, you have to be ready to unlearn. Stop feeling like you’ve mastered a particular framework or code just because your it successfully compiled.
As junior engineers, we often rush to the keyboard the moment they see a problem statement. We find the file, skim it, and start typing. This leads to "trial and error" programming. However, remember that the planning phase is just as crucial, if not more. We need to pause and ask why: "Why are we building this feature?", "Who is this feature for?", "What are the requirements?", and many other questions.
Let's talk strategy. If you want to kill the "code anxiety" I mentioned earlier, TDD is the cure. It forces you to plan because you can't write a test for something you don't understand. The cycle is as follows:
TDD ensures your code does exactly what you intended.
When you’re at the keyboard, be mindful. I like to think of my code like a painting on a canvas: it should be intentional and consistent. I’m talking about the small things: the spaces, the indentations, the naming. There isn't really any other way to feel truly confident in your work than having the mindset of outputting code that you feel is perfect and bug-free from the get-go.
Granted, linters and formatters can help you make your styling consistent, but they can only do so much for your habits. Think of them only as tools to fix the errors you missed, not as a replacement for your own discipline. To achieve that worry-free mindset, you should aim for your code to have the same high quality whether you're using those tools or not.
Enough yapping, here are two specific principles I consciously keep in mind every time I write a line of code:
A class or function should do one thing and do it well. If you find yourself using the word "and" when describing what a function does (e.g., "This function validates the input and calculates the length"), it’s time to break it apart.
As juniors, we love to overthink (because we feel like we know it all and we just need to spew out all the technical terminologies that we know of) and over-engineer. We think, "What if we need to support so-and-so requirement later if the user asks for it?" and we build complex systems for a problem that doesn't exist yet. Don't. Build for the requirements you have today. You can refactor later if the needs change.
Becoming a mature engineer isn't about how fast you type or how many concepts you can spew out in a 45 second time-window like some sort of speaking drill (IYKYK). It's about how much care you put into the "why" and "how". By adopting TDD and keeping your logic simple, you’ll stop feeling like your code is "slop" and start feeling like you truly understand what you've done and you've outputted quality code.
Hope this helps!