The role of forethought for a computer engineer

If you have ever played a game of chess against someone good, or perhaps against a computer, you know that a good player is always thinking multiple moves ahead, working every combination of moves their opponents may possibly make, and getting a plan for their next set of moves. It is a fun game, but very frustrating if you are just a novice because there are many ways for the game to be over super quick, leaving you feeling stupid.

Being a DBA and/or a database programmer is like playing several chess games simultaneously. Each opponent is formidable, crafty, and unlike a chess-playing computer, completely unpredictable. This unpredictability has led to software development methodologies that seek to manage this problem. But just like chess, if you have no forethought of where your opponents will move next, it can only exasperate your problems. You know your opponents and are probably good friends with many of them, which can leave you vulnerable to their whims.

Most of these items pertain to anyone working with the process of writing and maintaining software. Even if you are not a dedicated data-oriented programmer, you are going to have to think about the data too!

• Customers – Without customers, being a DBA would be the same as being unemployed. Luckily too, customers are reasonably predictable with a bit of coaching. They have wants and needs but can only be satiated by working software delivered regularly enough. Just talking to them, documenting their future needs (stuff accomplished well by employing agile methodologies), and giving them results regularly can help you to avoid their unpredictability.
• Hardware – Any DBA worth their weight in Jelly Babies knows that their hardware will fail someday. So we build servers to allow for minor failures and replace servers nearing the “mean time before failure” zone. We backup resources and store the results somewhere safe like a cloud provider, or at least offsite storage (probably not your mom’s garage for security reasons!) Don’t forget to test those backups and maintain hardware that can also accept your backups!
• Software – With every edition of SQL Server, more and more features are placed on the deprecated list, meaning someday that feature is going away (I was personally hit by an archaic form of RAISERROR that I used over 10 years ago in code that hadn’t been touched in years.) Even though deprecated features generally work for years, going through your code (or in SQL Server using Extended Events) to see when deprecated features are being used, and then using newer features will help you avoid future failures.
• Complex Requirements – You can tell the quality of a database programmer by looking at a complex stored procedure they have written. The novice often says: Ok, I need rows from X WHERE X.I = 1, and do that query into a temp table. Then I need to remove rows where X.J > 0, so they create a temp table of those rows. By the end of the coding task, they have 100 temp tables to return 3 rows, with all the temp tables just being stuff that could have been done with a few subqueries of compound WHERE clause criteria.

  If you are unsure of whether complex code, you can generally be 99.9382% sure of the quality of that code by reading the comments. Or lack of comments. 

• Database State – The most significant difference between database management/coding and other programming disciplines is maintaining state. And when you move from one set of structures to another, you must upgrade that state along the way. So as you are thinking about new features you want, it is essential to realize that whatever you build will not be easy to change without maintaining the existing data.
• And so much more – Unlike a game of chess, there is more to what you must deal with than just the pieces you can see right in front of you. World economics, your or your family’s health; changes in management; new products; changing technologies. And so on. 

In the end, the process of going from newbie to junior up to senior and architect level in a technical career requires a lot of forethought to be in constant preparation for what is next. And it is not untrue for almost any career. Keep yourself firmly grounded in making today’s business run, all while ensuring it runs well tomorrow. 

If this all sounds complicated… then you have grokked what I am saying and are ready to start the next phase of your training. Doing your best to make it happen. And don’t be afraid you are going to fail. Because you are. And you will learn as much from your failures as anything you read.

The post The role of forethought for a computer engineer appeared first on Simple Talk.

from Simple Talk https://ift.tt/uWjlXZC
via