Sat, 11 Apr 2020 05:20:43 -0700WeeblySat, 06 Aug 2016 14:57:20 GMThttp://softwarebrew.com/blog/if-youre-trying-too-hard-youre-doing-it-wrongAs a seasoned software professional I can attest to that myself.  There have been times in my career where I was bending my code into a pretzel to accomplish the desired functionality.  It was only by working with team-members who were either senior to me or just knew more about what I wanted to accomplish did I learn this.  The epiphany of this lesson came in spite of the fact that there had been times in my career where I was the more knowledgable team-member who shared the tips and tricks I knew to accomplish the desired functionality in a much better way that saved countless hours of extraneous and unnecessary code.  We as software professionals are constantly learning new languages and technologies and, sometimes, it's easy to forget that "if you're trying too hard, you're doing it wrong!"

One of the practices I've always advocated is that if you want to be "great" software programmer you need to learn the tools available to you and "use them to their fullest."  Most times a software project involves a database.  I'd be remiss to leave out that a programmer cannot be "great" without having a solid foundation in databases and advanced SQL queries.  Why is that?  Here are a few reasons to explore:

• One can eliminate extraneous code that could be bug prone and difficult to understand and maintain by replacing it with eloquent advanced SQL queries.  If you're using a database, let the database do the heavy lifting.
• A solid understanding of Normalizing a database to the third-normal-form is equally important as understanding good Object-Oriented principals and practices.  No amount of eloquent code in any language can fix a bad database design.  Rarely is a bad database design "unfixable" but sometimes the fix can be extremely difficult and costly, especially if the database has already been deployed to customers.
• Performance!  I once wrote a SQL query with three tables joined to fetch what I thought was a relatively simple query.  When I ran the code the query was taking way too long.  After reconsidering the original SQL query, I instead used a Correlated SubQuery, which returned the results instantaneously.  There are plenty of performance tools to help you tune your SQL queries but ultimately you need to know when you use a simple query, a SubQuery, a Correlated SubQuery, a self-join, and all the other Data Manipulation Language (DML) queries available for increasing your DML performance.

The information I've provided is just the tip of the iceberg.  I would love for others to please share your experiences with this topic to provide a more robust and comprehensive source of information for the larger Software Professional Audience.

Thank you for taking the time to read,
​Patricia]]>