We've all come across code that's written so craftily that it takes us some time to figure out what's actually going on in that block of code. We've never written things like that ourselves of course....seriously though, if you're collaborating, not doing things in the simplest terms will create an issue when other people start to look at your code. There is something about us; when we have an opportunity to show off how smart we are; we really try to go for it. The point is that it's not helping anyone and crafty code !== good code.
So what is "good code"? Good code accomplishes it's objectives as simply as possible. Good code has thought behind it, whether your talking about designing a full application or adding functionality to your methods. Good code is conscious of resource consumption and resource allocation; redundant code uses resources inefficiently. So now that we have a general sense of what makes code good, how can we ensure that we're keeping things simple?
Know your tools -There's really no reason to not use the manual, if you're using PHP there are a lot of things that the language will take care of for you. If you find yourself writing any sort of algorithm that deals with arrays, check first. That's actually the biggest area where I've seen 10 lines attempting to accomplish the same thing as one function. Use what's available to you, if you think you have a special case use what you can to make that process easier.
Know what you're doing- Understanding the requirements goes a long way to ensure that you're doing what your supposed to be doing. Looking back at the times where I've found myself in this spot, it's almost always been because I didn't understand the requirements correctly. All the effort you're pouring into figuring it out is completely useless if you've missed on the requirements. If you deliver no more and no less than what the requirements are asking for; you'll typically keep yourself out of trouble.
Check your smells - There are times where you can paralyze yourself with over-analysis and you have to start writing code even if you don't know the best way to start. Coding by smell has been an effective tool for me; if you aren't familiar with the phrase it's pretty simple. There are certain things in code that can give them a bad smell; one example is very large if-else conditional blocks and switch statements. That's not to say these smells are always wrong, but I've trained myself to re-evaluate what's going on when I come across certain things. It's really helpful when you are designing classes, there are times where the answer I've been seeking becomes obvious once I start writing components and seeing how they need to interact. It takes practice
What value does this add? - If there is something you are adding and you aren't sure why, ask yourself this question. What value am I adding to this method? class? project? code base? If you don't have an immediate answer, check yourself. This is always a great time to back through the list above. Make sure you are using the correct tools, to solve the appropriate problem, as efficiently as possible.
We all have a sense of needing to prove ourselves, and to some extent we all do. Whether it's to ourselves, or to people that are running an open source project we'd like to contribute to or our bosses. When experienced software developers look at your code and scratch their head, that's generally not a sign that you've stumped them with your brilliant take on something. If you are just getting involved or looking to get better, the previous scenario makes it really hard to get constructive feedback that helps out. By simplifying things, you give others a chance to look at what you are doing and help you understand what you did right and what you can do to improve that section.