I recently went through the hard drive of my father's super old Dell Inspiron 531 computer that I used as a child. When going through it, I found old eclipse projects from late 2014/early 2015. This inspired me to make a blog post detailing some important lessons I've learned after almost 8 years of developing.
My experience
I first got into writing code from Roblox. In 2013, I played lots of Roblox and am not ashamed of it. A core mechanic of Roblox is being able to create your own games, and using an in-game Lua engine to write 'scripts' for the games. This was my first introduction to programming, and while I wasn't very good at it, I found it enjoyable to play with logic and computer language.
A year later, I began playing Minecraft, and Minecraft allowed players (sorta) to create code that was linked into server execution-- Essentially being able to create DLCs for Minecraft. These were called plugins, and there was essentially nothing you couldn't change about the base game inside your code.
I started writing basic things like printing hello to all players whenever someone broke a block. It evolved into making new items, making new mechanics, until it eventually evolved into a pseudo-business. I began writing code and selling it for money (I was like 14, so it was usually around $20-$50). I'd stay up all night and write code for clients, and also put them on the public marketplace. I entered an informal contract with a large server that hosted over 300 players concurrently at all times, and was paid to do general server maintenance, patches, and mechanic additions. The owner would pay me $100-$200 for each new thing I made, and some of the things I made were really awesome. You can find most of my newer plugins on my GitHub. Unfortunately, when I did not start using GitHub until fairly recently, so many of the projects are missing and the ones that are there were uploaded retroactively in a single commit. A few of the bigger plugins I made include Olympus Tools, Crash Gamble, Purple KOTH, Craftcha, Purple Duels, Mine Bombs, Plot Mines, and Epic Util X.
So with that out of the way, let's start with a few things that my experience has taught me.
1. You need to enjoy writing code
As the heading suggests, in order to be a successful developer, you need to genuinely enjoy writing code. And this does not stop with the occasional "yeah, writing this code was kind of cool I guess", but instead refers to "I'm going to spend my whole weekend writing this code for fun". Much like with most fields of work, having an interest is very important. However, with software development it is not only important but critical. If you do not enjoy it, you will burn out very fast and the quality of your code will go down. You will hate every minute of your life and you will limit your creativity and code quality.
2. Conventions exist for a reason
Writing code comes with a lot of conventions you are expected to follow. Many languages have standard practices such as bracket placement, indentation, comments, and variable naming. These conventions are almost exclusively designed to make your code easier to read and understand for others when collaborating. When writing code that will never be shared you'd think that these are not important, but unfortunately it is always important that you follow (at least somewhat) these conventions. I've found that writing formatted comments and using variable naming schemes has helped me understand my own code better. When you write a program, you are the de-facto expert on that piece of software. You understand your own code better than anyone else in the entire world. However, while you may understand the flow and concept of the code, often times leaving comments explaining or using flow control will reveal things about your code that even you did not think of.
3. Don't reinvent the wheel
This one has been the hardest for me to learn. It took my boss telling me this every month for it to finally stick. Every problem I had, I wanted to develop a large-scale program to solve. The problem was that these programs already existed. So instead of having a great idea and spending 5 weeks making it, only to realize it has already been done and is on Github with 3,000 stars, make sure you look and see that your idea has not already been done. There is something to be said about if you need the program for in-house usage or specific needs but if there is a public project that works, your time is better spent expanding on that project instead of recreating it.
4. There is no correct way
When it comes to code, there is no right way to write. Some people take breaks every hour to clear their head, and others spend 6 hours straight fully engulfed in the code. Some people may use debuggers and complicated pipelines, while others prefer to use the (clearly superior) intermittent print statements to debug. Everybody will tell you different things when it comes to how to write, debug and test but the bottom line is that whatever works best for you and produces the highest quality code is the correct way for you. However if you are collaborating, then there will be certain things that you have to do. This is unavoidable and an unfortunate but necessary aspect of the collaborative development work.
Part of the joy of development is seeing how you as a person develop. Your code quality will improve, your style will change, and your skills will increase. Going back to see old code that you wrote is one of the most humbling things you can do-- Nobody starts their development path writing good code. It's always bad, and if you stick with it, it will always get better.