Some Beginner Tips for Better Software Development

So you are new to programming and you want some quick and easy tips for making better software. Sure there are ton of sites out there talking about all these subjects on code structure and best practices, but which ones can give you some immediate bang for your buck? Which ones should you follow right out of the gate to get off to a great start? We have compiled 6 different tips below that should help you avoid many mistakes and make the whole programming experience more pleasurable.

Tips for Better Software

• Ask for Only What You Need – In our programs we have a tendency to ask for more info than we need. We might query databases for 1,000 records when we only need 10 or ask for all fields of a database table when we only use one or two. Perhaps we ask the user to enter in their age in addition to their birthday or ask for their favorite color just because we are curious rather than actually needing it. All this extra data we ask for does only two things really really well. First it muddles up the problem and adds complexity. Why ask for an age if we know their birthday? We can calculate their age. If you can calculate it, then don’t ask for it. The second thing it does well is decreases performance. If we have to iterate through 1,000 records we are going to take more time than if we iterate through 10. Why pull across 1MB worth of content on the web when we only are interested in 1KB? Be mindful of how much you are asking for and how much you are actually using. If you are finding yourself using select * then you might be asking for too much info.
• Don’t Cloud Yourself with Abstractions – Lots of groups and sites out there tell you that abstracting out ideas are good and that you should do it whenever possible. Yes it is good practice to make abstractions where they make sense! One video I saw recently talked about using a simplified design structure by removing layer upon layer of unneeded abstractions. I have seen code that takes a very simple straight forward solution and bloats it with layers of useless abstractions. All these abstractions meant that if you want some info from a data source you will have to sift through 4 or 5 different classes, functions or APIs just to get at the data. I have seen code that takes an array of strings, puts it into a structure like a generic List<> and then converts it back to an array everywhere because that is what they needed, an array, not a list collection. In fact they never even used the List collection’s advantages. Look for the most simple solution possible first and when you find it, then see if perhaps an abstraction is needed. If it is not going to reduce the complexity further, not help you reuse code, or provide you any immediate advantages then don’t use it! No matter how cool it might be!
• Be Your Own Programmer and Use What Makes Sense – There are going to be a lot of programmers out there, some well respected and others not so much, that are going to tell you tool XYZ is the only way to do things. Referring back to an earlier point, never use an array, a generic List<> is the only way to go! I say use whatever feels right for the situation and don’t be afraid to break the mold and try new things. 9 times out of 10 they might be right that a List<> is better or they could be wrong 9 times out of 10. In other words, don’t be a mindless sheep programmer and evaluate arguments yourself. Years ago the foreach was being touted as the best thing since slice bread and a ton of software was being created using it. Who cares what the situation was, foreach all the way! Well now research is turning out to be saying that a for loop has a lot of advantages over a foreach when it comes to performance. I am not saying one is better than the other, but go with what you know and realize that there are trends in programming like there are trends in fashion. Some of them were a hit and some where a huge mistake… like shoulder pads! Blazing your own path will help you discover, learn and may even lead to somewhere no one has ever been before!
• Optimize Last – Write what works and once everything is moving in the right direction, then go back and ask what could be better. You can spend an eternity optimizing code and if you do that during the actual writing of the code you may never ever finish. I am a strong believer that you should get something up and running and then optimize. It will help you in industry too because you will be seen as someone that can get software models working quickly, you are flexible to change and not afraid to throw away some code (because you didn’t spend hours optimizing it). But do make sure that the code performs reasonably well before you finally let it go into the world. Reasonably well is not “fast as possible” but more like good enough to meet reasonable expectations and goals.
• Fight the Temptation to Create Everything Yourself – Beginners and experts alike love getting their hands dirty writing new code and will recreate the wheel a dozen times until they get sick of wheels. If someone has already written a great wheel, use it and then get on with the unique and challenging parts. If you are bogged down building wheels and levers and buttons how are you ever going to build the next super sonic car? But one thing should be said about this… whatever wheel you use, learn as much as you can about it. Never use something blindly because if it breaks, you may be expected to fix it.
• Vet Your Resources – As you program you are going to look at many websites and docs, listen to speakers and watch presentations. Keep an open mind to the ideas, but always ask yourself how reliable and trustworthy is the resource. I have seen many new programmers preach from w3schools.com as if it was the bible. Yes it is a good site for the basics of HTML etc, but it has been proven many times that the site also has some inaccurate or gaps in information when it comes to more advanced topics. Use it, but also understand where it falls down. Once you have vetted a resource, then you know how much you can trust it for your own learning.

Conclusion:

If you ask for only what you need to solve a problem, avoid fancy abstractions you may not fully understand, be true to yourself, go with what you know, avoid optimizing like a mad man/woman while not creating everything yourself and vetting your resources, you will quickly learn what you need to know about programming. When you avoid all the unnecessary data to make the problem harder and go with what you know you are going to write better code. Yeah it may not be as advanced as the next programmer but advanced is not always good. Sometimes the turtle wins the race because the rabbit used a car that eventually broke down. Thanks for reading! 🙂