My music professor at university was one of the most influential people I have ever known. A particular piece of wisdom struck a chord with me. “How much better would you be, if all your teacher had told you to?” The point of his message was not to blindly obey what is told. He meant to say that once we become familiar with a discipline enough, we will know how to improve. We know which habits, mindsets, and procedures will help us become better at our work.
It’s obvious that he would not have said this remark had we You can also find out more about the following: Do what you know to be right. Why? Laziness is the most likely reason, but there are others.
It’s hard work to address all the fundamentals. And it’s not as much fun as doing flashy things. Would you rather build the penthouse or the foundation of a skyscraper? We do not appreciate the sturdy foundation until we find out, sometimes catastrophically, it is faulty.
Inspection Time
In that spirit, i wanted to be an engineer who was responsible and examined our foundation. These observations are based on my experience in software engineering. These practices, however, are applicable to all disciplines. Each one has an example where it was the deciding factor in success.
Check all assumptions. It is alarmingly common to accept a “truth” as a given when it is not. The first step in solving a problem is to examine assumptions. This is because assumptions that are able to withstand scrutiny will determine which solutions remain viable. Imagine how devastating it would be if your planned strategy was built on an invalid or unfounded assumption. Why risk it?
Recently, I was involved in a project which aligned software deployment with an industry standard practice. To meet specific requirements, however, the leadership of the project relied on a unique definition of common terms that deviated just a little from industry standard definitions. If I had relied on the usual industry definitions, some requirements would have been missed.
You can look up any term you’re not sure about. It’s easy to assume that we’ll be able to intuit a new term from its context, or that the word is marginal enough that we’ll get the gist of it without it. How can you be sure? How can you be sure that you would not understand the topic at a deeper level if it took you five minutes to research it?
I was not familiar with object-oriented programming when I began my crash courses in computer science. “Yeah,” I thought “everything’s an object.” When I looked into the details I discovered the traits that define object oriented programming, and how they dictate the way it is applied. Then, with enough background knowledge, I began to think about what problems object-oriented programming is good for and which it is not.
All your sources should be checked for credibility. I’m not telling you to only read the documentation (although it’s wise to start there), but you shouldn’t ascribe credibility to a source until you’ve checked it against information you already know is credible — like the documentation. I’ve written several articles about the differences between the widely accepted way and correct way. Recently, I wrote an article about Linux DNS configuration It is a great example.
I am constantly surprised by the wide gap between what is in the documentation and what forum developers are confidently claiming. I had to create a lot of code. RFC 4122-compliant UUIDs. Many developers in the language I used recommended using a third-party library. Upon careful research I discovered that the cryptographic library built into the language was capable of generating UUIDs. By omitting this third-party package I was able to reduce the number of dependencies and the attack surface on the application that I was developing.
Take some notes and then take more. In the past year, i have taken it upon myself to record any stray thoughts, internalized or synthesised, rather than letting them go. Since then, even though I don’t read my notes again, I am more productive and absorb information. It’s intuitive that taking copious notes will help you learn more. It takes less time to take too many notes and then scan them all than it does to write too few and have to go back to the source to find what you missed. It is even more important to take notes on digital devices. Ctrl+F searches of massive notes files are far quicker than retracing the investigation.
I wrote down the criteria for selecting configurations as I researched how to configure and then test certain applications. I wrote everything down on a private page of documentation, and even created a flowchart that illustrated all my considerations. Initially, I created the page to reinforce and check my understanding. Once I realised that other developers could benefit from my experience, I had already created a page.
Test everything that you build or design. Test everything you design or build. A recent study found that most people do not take the required tests. study Just under half the time, professionals in information security do not audit major updates of their applications. You may be tempted to think that your application should work fine if you look at it on paper. But if everything worked like it did on paper, testing would never find any issues — yet so often it does. Testing is all about discovering what you did not anticipate. Since no one can anticipate everything, testing is the only option to discover what you missed.
A program I wrote to check a payload response that contained data structures of different types nested arbitrarily was a good example. Although there is a common data structure at the top of these payloads (the payload root), I wrote the code to accommodate a wide range of top-level structures. During development, I added flexibility only after testing with a range of payloads. If I had not tested the program with unusual or unexpected inputs it could have been prone to edge cases which led to a failure.
The Basics aren’t everything, but just the things that everything depends on
Why do I keep coming back to the same basic questions? Two reasons come to mind.
First, I have personally seen the benefits. By putting each of these into practice consistently, I have improved my work and am now able to take on more complex issues. It would be impossible to do the work that I am doing today without solidity in these fundamentals.
Second, by adopting cutting-edge technologies, companies are able to extract more productivity out of their employees. Generative AI is just the latest example of this trend. Do not confuse the means with the end: Companies aren’t necessarily interested in generative AI, or any other tool. They want to increase productivity.
It’s still too early to tell if generative artificial intelligence will make the quantum leap many believe it will. Why not use the current paradigm to its fullest before adopting a new one? It is more efficient to focus on improving the basics rather than adding a new factor.
In any discipline, the majority of what you do regularly relies more on basic skills. Pareto Principle in action (also known as “80/20 rule”): 20% of your skill set accomplishes 80% your work.
My teacher says that mastery is really just refined basics. Do not overlook the path to mastery just because it seems unassuming.