From my experience there are (at least) three mental stages you experience throughout your software developer journey.
- The Oh-my-coding-is-so-fun-look-at-my-hello-world-phase in which you basically start to understand that coding is not like it is shown in various movies – it is way better.
- The It-mostly-works-but-does-not-look-good-phase consisting of you starting more and more projects (but never finishing them in many cases known to me) and trying to build up your skills by simply doing. This basically means that you already have accumulated skills and some knowledge in this field by now, but, because of the lack of experience, you sometimes fail to apply it all in the right way.
- The I-am-confident-and-know-how-to-approach-a-problem-phase, which is the phase of you (mostly) produce working, and (mostly) clean and well-structured code. This phase has the distinct mindset characteristic of “My (now complex) code works and I know why”, which you can only be convinced of if you are sure of your skills and knowledge, and know how to use it.
As far as my experience goes, the first big goal is to reach the third described phase. The biggest problem with this is mostly impatience. As mentioned earlier, I see those phases as some kind of mental stages, or you could call them mindsets, and altering your current or rather switching to a new one takes time – We are approximately speaking of years here.
But of course, as engineers we want quality time, in which we maybe even made the world a better place, and not just a pile of wasted hours in our resume. So, how do I gain the mind of a phase-three-software-guru?
Good Design Is Key To Good Software
You know the drill, the syntax, the keywords, but all of your real-world-to-code-translation is neatly stacked into the main-method of your application. Surprise, surprise! – You should not do that.
Especially in the object-oriented field, you should get to know design patterns. There are so many solutions for your (more or less) generic problem out there. Of course most of them need a little tweak here and there to fit your needs, but they give you an insight into the head of a much more advanced developer without having the need of actually attend a course or contact one.
It may seem scary at first having to deal with multiple methods, classes or even projects, when implementing your own libraries, but by organizing, separating and designing your code as it deserves to be designed you surely will step up your game, make your software more testable, readable, scalable and, above all, easier to debug.
To be confident you have to feel confident (Disclaimer: Easier said than done, I know)
I know, I already mentioned that a few times now, but I can not emphasize this enough. I know of so many students, and also professional developers, who just seem to be unable to give any kind of credit to themselves for their good, sometimes even up to extraordinary, work. What many appear to fail to take into account is their current skill level. Of course, you may think that your code is rubbish (and some more advanced developers may agree with this point), but is it that bad considering your knowledge? Did you give it the best you could have done at this point of your career? If you answer these questions with yes and you still feel like there is an even greater potential – go and work for it!
Try to take criticism as a learning opportunity – Let them dare you and show them what lies within you!
Give up the idea of perfection
Lastly, I can not say the previous without mentioning this one - Everything in moderation. As I said earlier, work towards quality when trying to improve yourself, not quantity. There is no point in you despairing because you can not seem to boost the performance of you code even after hours of staring straight into your dimly glowing misery.
Above all, keep an open mind, confront yourself with new challenges in life – also apart of coding – which will help you grow as a person and therefore may provide you with a head-start for reaching the next phase.
Top comments (1)
I think this is such a key part of being a good engineer - it's the foundation of taking decisive action. And following on your last point, a decisive imperfect decision far outweighs the indecision in finding the perfect answer.
Thanks for the post :) really enjoyed reading it.