[I've worked 3 years within the Sustained Engineering Team at Fiserv, a mobile banking company based in New Zealand. Even with 4 years of experience under my belt, I was amazed about the things I actually didn't know and over the time I realized there were a lot of small things I was doing totally wrong.
What I'm about to write is not the holy truth and I might not cover everything but I hope by sharing my amusing own experience, you'll avoid my mistakes.

Getting comfortable

I worked on a Stat tracking app on iPad, called StatEdge. The whole idea of the app was to track numbers, save it locally and being able to synchronize with a distant database.
Because in the past I wasn't used to work with CoreData but a sqlite3 database, I decided to stick to it ; needless to say it was a pure nightmare. The client needs changed every day and so was the database structure. At that time, Parse was still recent, and I never heard of Couchbase and other NoSql solutions yet.
Back then I was avoiding to use Storyboard and kept using xib files and pushing my screen in code (and not using segues...). I had 2 years of experience before that and my previous company didn't use storyboard so I kept that (bad) habit.

Write a Massive View Controller

Have you ever opened a xxxViewController.m file and realised that it's about 1-2k lines long, calling punctually a singleton called xxxService which handled all the network or database functions ? Believe me or not, but putting #pragma mark and even organizing your code by logic order (view cycles, tableview delegate/datasource, UI customization, ...), it's still a nightmare for yourself, and more for the poor developers who will maintain your code afterwards.
I've recently got handed over some project made by other developers with years of experience, and it doesn't prevent them to have a MainViewController handling all the call of the app. I have one file which contains 20k lines of code (yes yes it's true).

Patching things, not fixing

When I was stuck for too long on an issue, I would fix a bug by trying to arrange the result to match the expected result, and not fixing the inner cause. It would have been forgiveable in a world without peer code reviewing, or if you are the solo developer of a lonely agency. My younger self would always said "It works" but I couldn't express or spot the real problem.
It's even more true when you are working under a really pressured working environment, and the bugs are being accumulated at the point speed is prioritized above quality. No mather what you do, if the commit isn't good quality, you'll pay the consequence in the near future.

Forget to clean your code

Let's all be honest, when something is not working we will pollute the codebase with a lot of logs which will appear in the console after running the code. Yes, i'm talking about those NSLog(), or debugLog(), or comment such as // TODO : it's not working here (#warning also). I've opened an old project I wrote years ago, an english quiz app, and believe me I've never seen so much useless stuff needed to be cleaned.
A cleaner code is also moving litteral string (text for alert message, titles, contents of labels), or numbers (age, a specific amount, a size) to a proper constant value. I used to overuse macros #define but I now find more elegant using a variable instead ; personally I prefer to see something like :

let messageToDisplay = Constants.Alert.AddedPlayer.Message.Success

than

let messageToDisplay = ALERT_ADDEDPLAYER_MESSAGE_SUCCESS

Lack of communication

A good project will meet his end if all the different parties, the developer, the designer, the project manager AND the client understand each other. Yes it's true that it's always annoying to see his code having to be rewritten because the client decided to change his mind. A younger me would have been pissed to replace those two buttons 10 pixels higher because the designer said so, or that have to rewrite an entire module because I didn't get it right. I would be moody, stop talking to people and barking if there was slightly too much pressure.
Now I would spend more time in meetings, make sure that everyone knows what my changes would imply, give an estimate to my project manager and warn if there will be some issue most likely to happen, have long talk with my designer. Communication is key, and the age when a developer would be a little creature coding on his own is over!

Be a better developer ... everyday

I really wanted to share my own experience, I think there's a lack of articles on the web about the daily life of a developer. It's really personal and obviously I might have missed a lot of things but I wrote that article trying to remember what I used to do wrong, and believe me in 10 years I could probably write more on what I'm currently doing wrong!
I hope this article will help the younger developer if you see yourself doing the mistakes I wrote above, and make the more experienced developer laugh