The book you see in Figure 1 is called “Running MS-DOS” by Van Wolverton and it nearly ended my software development career before it even began. In 1988, I moved to Bend, OR and decided that it was time for this 19-year-old prodigy to enter college and prepare to achieve his lifetime goal of becoming a writer. In the first term, I took four classes: English Composition 101, Desktop Publishing, Introduction to Business Applications, and Editing. It was during this first term that I came to the realization that I liked the computer stuff more than the writing stuff (I bet Melanie will love that statement [Ed:
Every week, we went through a number of exercises from the book. For instance, we learned the dir command. We used the dir command to list the contents of a directory and to show the date and time on files in a directory. We learned how to use wildcards to search for specific files. My strategy was to read, re-read, and re-read the chapter again in an attempt to remember the confusing syntaxes of slashes, back-slashes, wild cards, switches, etc. Then I'd take the test, which typically resulted in a CRASH and BURN operation. I was barely eking out 60s and 70s on the tests. What the heck? I read this stuff up, down, and sideways. How could I be failing? I went to my instructor with my frustrations and he asked, “Are you doing all the labs?” I told him that I was doing some of them but that I was reading the heck out of the stuff in the text. He said, “You need to focus more on the labs and less on the book.” I promised to give it a try.
From that point on, I spent a lot more time in the lab and a lot less in the book. You know what happened? All of this MS-DOS stuff stuck. Finally, I was on track and began acing all my exams. I was off to the races. Next term, it was Advanced MS-DOS (batch files, baby) and Intro to Database Development (dBase III for the win). Sometimes a single discussion can be a life changer and the chat with my advisor was definitely that.
The point of this story is simple: Software development is an applied science. You can't become a software developer by reading a book (or Stackoverflow); you need to apply this stuff. It's applying the science that makes it stick. In the last issue's editorial, I focused on small life lessons that have helped me through my career. One I overlooked was the “applied” part of the science. This last month, I reached a breakthrough with my new developer. I got annoyed that some stuff we'd been working on hadn't been sticking. So I asked him the same question my advisor asked me: “Have you been writing code to practice the stuff?” His answer was just like mine: “I've been reading the heck out of it, so I don't understand what's going wrong.” I told him to stop reading and start writing. You know what happened? He started doing that and is getting better steadily.
This is a lesson for you as well. You can read books, blog posts, magazine articles (keep reading CODE Magazine, please), and watch training videos, and yet still not understand the impact of a technology in your development life. It's not until you build an application (large or small) using a particular tool, technique or technology that you will really get it.
Over the last 20 years, I've written no fewer than four versions of my SQL-Server Stored Procedure Middleware. First it was in Visual FoxPro (two versions), then Visual Basic 6, then Visual Basic .NET and finally, in 2015, using C# with POCOs (Plain Old CLR Objects). Like all good developers, I spent time experimenting with different techniques, prototypes, and concepts. The first cut was very simple and handled mapping stored procedures to lists of objects. I immediately went to work implementing this first cut in production code. You know what happened? Some of it worked and some of it didn't. I improved the failing portion of the framework before moving on to doing CRUD operations on single tables. Then I went to work putting that into production as soon as possible. Rinse, lather, repeat. By putting this framework to real use, it got better and better. Without that technique, it would have worked only in theory and not necessarily in real life.
There's an old military saying that goes, “No battle plan survives contact with the enemy.” This is a perfect statement when it comes to the applied aspects of software development. Remember: "Your designs aren't valid until they've been implemented and faced contact with the enemy (user)"!
