Patrick's Programming Blog

2013 Resolutions Review

checklist
  1. Blogging for Benjamin Competition
  2. Why I'm Grateful to Work on the Web
  3. 24 Pull Requests
  4. Update Downloadable Product's Expiration Date in WooCommere
  5. Get Lost in the Flow and Work for More Than a Salary
  6. Why A Plugin's Popularity Matters
  7. Why You Should (Or Shouldn't) Use Premium Plugins
  8. WooCommerce Terms & Conditions
  9. Only Ship to Continental United States with WooCommerce
  10. Just Talk
  11. Why I Love Jetpack
  12. Making Jetpack Better
  13. Remove Billing Address for Free Virtual Orders in WooCommerce
  14. Notify Admin of Customer Address Change in WooCommerce
  15. Open Your Self Up To New Possibilities
  16. 2013 Resolutions Review
  17. Create a Community
  18. Tips for Starting a Community
  19. The Intent of Goals
  20. Create The Ultimate Invoicing System Using WooCommerce
  21. Change From Address in Ninja Forms
  22. Work With People Who Inspire You
  23. Contact Form 7 & MailPoet Integration
  24. Monotasking
  25. Giving Back to The Community
  26. Adding Fuctionality to Lean Plugins
  27. Choose Stripe For a Payment Gateway
  28. A Dip Into Entrepreneurship
  29. Reward Yourself
  30. Blogging for Benjamin Plugin
  31. Blogging for Benjamin Wrap Up

I've had so many amazing opportunities in 2013 so I'm really excited to start thinking about 2014. I definitely want to create some goals, milestones, resolutions, and avenues to explore in 2014 but before I do that I think it's really important to look back and quantify all the things I did in 2013. Both the good and the bad.

All of the goals in the world wont help unless you can clearly see your strengths and weaknesses and come up with some strategies to work with them.

2013 New Years Resolutions List

I think the best place to start is with what I actually declared as my new years resolutions for 2013 in my first blog post of 2013.

Write Better Documentation

I hate just as much as the next developer opening up a new project and seeing no documentation. It's really unfortunate that most projects are like this. Someone who's become familiar with the project certainly wont need all of those comments but if it's an open source project and you want people to understand your code and build extensions or submit patches then you need as much documentation as possible.

I'm a huge fan of inline documentation and I'm usually very verbose in describing what is going on inside a function. Here's a couple examples of some of the pull requests I'm quite happy with. They're only tweaking a line or two of code and I was still able to add some comments in describing what is happening.

While this is really good I think I can do better. What I'd really like to do better with in 2014 is making better end user documentation. Especially for my premium Ninja Forms plugins.

Get a Code Review

I actually did get a code review in 2013 but it wasn't all it was cracked up to be. I certainly learned a lot from it but I've learned so much more by continually submitting pull requests and receiving feedback on them. Instead of paying someone to review your code learn best practices by submitting pull requests and making the tools you use every day better.

Meet More Developers

Wow, I would definitely say I achieved this one! There's a few specific events that happened in 2013 to help me meet developers:

2014 Resolutions?

I'm not quite ready to write my resolutions for 2014. I've only listed the resolutions I had at the start of 2013 there were so many impromptu goals, and extra opportunities that I'm glad I went for. I'm also planning on talking to a few developers that inspire me to help me create some goals for 2014. Don't worry they're coming! 🙂

Exit mobile version