Very good insights. I have a hard time understanding why others do not understand how to debug issues. You have put it in a very good context.
It reminds me of my first development job out of school. First day on the job we had to undergo a month of training. On the tables was a legal notepad and a pencil. My instructor wrote a simple task to add two numbers together and display the outcome. Everyone started turning on their computers and he said to stop and use only the paper and pencil in front of us.
Every program we wrote during that training class was first written out with a pencil and paper and reviewed by him before we could enter the code in an IDE and execute it.
This process had a profound impact on how I code and how I perform testing.
Hi! I am a longtime developer with a passion to empower other developers to be their best. I focus on cloud development and everything related to data access from .NET and .NET Core.
I am thankful that I started out on simple 8-bit operating systems hand-coding instructions into memory. Not necessary today, but provided insights and an approach that has helped me master modern computing. With only 64k of memory and a slow CPU (2.6MHz) you had to really think about what the code was doing and reduce overhead and waste. Then you could reasonably step through every instruction to see what was going on. With today's frameworks a simple task like responding to a keypress and updating a view model can take you on a journey through code orders of magnitude beyond what you might expect. Thanks for the feedback and your thoughts!
I should have added we were writing applications in assembler directly in prod on AS400 mainframes. No room for error. Being off one bit can cause havoc; corrupt core memory and cause the whole thing to crash.
I only witnessed that happen one time in my career there and it was not a fun time for anyone. (No I was not the cause.) It caused a system-wide outage for major players in the airline industry. Fortunately, it is easy to roll back the changes in real-time so once the issue was identified it only took seconds to fix but there were a lot of unhappy folks in management.
I fear in today's world of IDE's, frameworks, and helper functions, we are no longer teaching developers how to think in systematic steps but in abstract concepts. This is one of the reasons debugging is difficult for people. The XYZ framework takes care of that, or I was told by developer Joe to just use this object for this function and that object for the other function. They have no idea what those objects are used for or how to use them properly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very good insights. I have a hard time understanding why others do not understand how to debug issues. You have put it in a very good context.
It reminds me of my first development job out of school. First day on the job we had to undergo a month of training. On the tables was a legal notepad and a pencil. My instructor wrote a simple task to add two numbers together and display the outcome. Everyone started turning on their computers and he said to stop and use only the paper and pencil in front of us.
Every program we wrote during that training class was first written out with a pencil and paper and reviewed by him before we could enter the code in an IDE and execute it.
This process had a profound impact on how I code and how I perform testing.
I am thankful that I started out on simple 8-bit operating systems hand-coding instructions into memory. Not necessary today, but provided insights and an approach that has helped me master modern computing. With only 64k of memory and a slow CPU (2.6MHz) you had to really think about what the code was doing and reduce overhead and waste. Then you could reasonably step through every instruction to see what was going on. With today's frameworks a simple task like responding to a keypress and updating a view model can take you on a journey through code orders of magnitude beyond what you might expect. Thanks for the feedback and your thoughts!
I should have added we were writing applications in assembler directly in prod on AS400 mainframes. No room for error. Being off one bit can cause havoc; corrupt core memory and cause the whole thing to crash.
I only witnessed that happen one time in my career there and it was not a fun time for anyone. (No I was not the cause.) It caused a system-wide outage for major players in the airline industry. Fortunately, it is easy to roll back the changes in real-time so once the issue was identified it only took seconds to fix but there were a lot of unhappy folks in management.
I fear in today's world of IDE's, frameworks, and helper functions, we are no longer teaching developers how to think in systematic steps but in abstract concepts. This is one of the reasons debugging is difficult for people. The XYZ framework takes care of that, or I was told by developer Joe to just use this object for this function and that object for the other function. They have no idea what those objects are used for or how to use them properly.