I have recently begun reading the book The Pragmatic Programmer by Andrew Hunt and David Thomas. It is an absolutely fantastic book. I have already learned quite a bit. Perhaps the best part of the book though, is the fact that it does not focus on any particular programming language. It is a great read that provides a plethora of knowledge to any developer at any level.

After only finishing the first chapter, there have already been so many points that stuck out to me. Actively keeping these points in mind will be a priority from this day forward.

Always Try to Be Aware of the Bigger Picture

This is something that I am usually pretty aware of. In fact, I think I may focus too much on the bigger picture. Because of this, I often place little importance on the small steps necessary to get there. This leaves me in a position where I sometimes have difficulty figuring out how to get to where I want to be. This will continue to be something I actively work on improving.

Take Responsibility For Everything You Do

This is of course extremely important as a programmer. I build programs to meet the needs of others. If something isn’t right, I should take responsibility for it. Doing this is a big part in maintaining a good relationship between my clients and users and myself. In addition, holding myself accountable is an important step in improving yourself. Not only in development, but in ALL aspects of life. Expect others to be responsible for their actions as well.

Provide Options, Don’t Make Lame Excuses

Blaming this or that for issues won’t solve anything. If I want something done a certain way, figure out how to get it done! Make a plan. Find a way. It’s as simple as that.

Don’t Live With Broken Windows

It’s easy to get complacent. Don’t. How many little issues in a project that I allow to exist does it take before my masterpiece is ruined? Two? Three? Fifty? Does anyone know? Allowing any of these things to exist creates a mind frame of entropy and complacency, and it doesn’t take long until that mind frame takes control over my project. I’m not saying I should expect perfection. I should, however, actively work to fix problems. Make a note of problems that exist in a project. David uses a great analogy for it; if I can’t fix the window, board it up. Comment the code out. Do whatever I have to do. But don’t let it remain as a stain on your masterpiece. If it seems like it may be a lot of work to be constantly fixing broken code, that’s because it probably is. But if I don’t fix it, broken code will ruin my work.

Stone Soup

This concept can not only be applied to larger things, like the software a company uses, but also smaller things, like an app I am building. Start with the small things that I know I can do, and do well. Build up from there. This goes back to the first point I mentioned. I need to recognize the small pieces I need to get where I want to be. From there, I can start adding stuff slowly but surely. The stones will not only serve as a building block, but a small, functional piece is usually enough to get others on board.

Don’t Be Like The Boiled Frog

This is absolutely something that has happened to me more than once on projects. I reach the end product, and it ends up being very different from what I envisioned. What I didn’t realize while I was working on it, was that small, incremental changes throughout development are what led to this. Whenever I do something, I need to think about he big picture. Think about the effect it has on the end product. Taking detours is okay. I just need to remember where I am trying to go, and make the necessary adjustments to get there. In my experience, development is not much of a straight path. I take an uncountable number of detours on every project. Getting to where I need to go is the important part.

Invest Regularly In Your Knowledge Portfolio

I have really enjoyed the process of learning in my time as a developer. Learning new technology or reading new books, as well as learning more about the technology that you are already familiar with, keeps it so that I am always valuable. It increases my “net worth” as a developer. The only thing keeping me from working my dream job is my skill set. That’s it? Really? Skills can be learned. They can be improved. If there is something I don’t know, learn it! It will only benefit me down the line.

Communicate!

This is probably my biggest problem. It has been a problem most of my life, in most aspects of my life. Communication solves so many problems. If there is a problem, say something! If I am not sure how a certain program works, I need to speak up. If I don’t know how to proceed, ask for help. There is nothing wrong with asking for help. Communicating with my clients or my boss will ensure that I understand their wants and needs. This, in turn, increases the chances that they are happy with the outcome of my work. If there is anything that I read in the first chapter that I have to remember and actively work to improve, it is this.

Make It Look Good

A functional app is cool, but if it looks boring, no one will care. Presentation is just as important as performance. Make it look good. Take the extra time to clean it up. When I am presenting something, go in there prepared. Know what you want to do, and make a plan that describes how you are going to do it. Mason (my instructor at The Iron Yard) was a big proponent of indentation. It may not seem like something that is a big deal to some people, but it does matter. It makes code look clean and professional. It makes code easier to read. This, in turn will make people more willing to work on that code. People are drawn to attractiveness. It is programmed into our biology. If I keep this concept in my mind, people will be much more interested in my work.

And that was just the first chapter! I am extremely excited to read more of this book. Big thanks to my sister Ashley and her fiance Drew for recommending it to me. This things I read in this book will no doubt make my journey as a developer, as well as my journey through life, more focused. I can’t wait.