As you probably know, I started working on softwarephysics back in 1979 when I transitioned from being an exploration geophysicist, exploring for oil with Amoco, to become an IT professional in Amoco's IT department. I then spent about 20 years in Applications Development as a programmer and then 17 years in Middleware Operations at various large corporations. I am now 69 years old, and I retired from my last paying IT position in December of 2016. My son is also an IT professional with 17 years of experience. Currently, he is a Team Lead in Applications Development doing Salesforce Cloud Computing for a small investment company. When I first transitioned into IT from geophysics, I figured that if you could apply physics to geology; why not apply physics to software? So like the exploration team at Amoco that I had just left, consisting of geologists, geophysicists, paleontologists, geochemists, and petrophysicists, I decided to take all the physics, chemistry, biology, and geology that I could muster and throw it at the problem of software. The basic idea was that many concepts in physics, chemistry, biology, and geology suggested to me that the IT community had accidentally created a pretty decent computer simulation of the physical Universe on a grand scale, a Software Universe so to speak, and that I could use this fantastic simulation in reverse to better understand the behavior of commercial software, by comparing software to how things behaved in the physical Universe. The original purpose of softwarephysics was to explain why IT was so difficult, to suggest possible remedies, and to provide a direction for thought. My hope was that softwarephysics might help the members of the IT community to better cope with the daily mayhem of life in IT. As we all know, writing and maintaining software is very difficult because so much can go wrong. As we saw in The Fundamental Problem of Software this is largely due to the second law of thermodynamics introducing small bugs into software whenever software is written or changed and also to the nonlinear nature of software that allows small software bugs to frequently produce catastrophic effects. In later postings on softwarephysics, I explained that the solution was to take a biological approach to software by "growing" code biologically instead of writing code. See Agile vs. Waterfall Programming and the Value of Having a Theoretical Framework for more on using an Agile biological approach to software development.
People-Problems Also Contribute to the Daily Mayhem of Life in IT
However, most of my efforts over the years have always been focused on the physical constraints that contribute to the daily mayhem of life in IT. In Hierarchiology and the Phenomenon of Self-Organizing Organizational Collapse and
Don't ASAP Your Life Away I did briefly touch upon some people-problem issues. But as I watched my son graduate from the University of Illinois in Urbana with a B.S. in Computer Science and then begin a career in IT, I frequently found myself counseling my son about the common people-problems that can occur in IT and that can also heavily contribute to the daily mayhem of life in IT. It may be true that the root cause of all IT problems can be traced back to the second law of thermodynamics and nonlinearity, but it is also true that nearly all of the real day-to-day problems that arise in IT come about from how the people around you deal with the second law of thermodynamics and nonlinearity. It also depends upon how you deal with the second law of thermodynamics and nonlinearity too! After all, if you could write perfect code off the top of your head that always worked the very first time and never failed while in Production, all of your IT problems would immediately go away! Unfortunately, so would your IT job.
If You Are an IT Professional You Need to Watch Jayme Edwards' The Healthy Software Developer Videos
So here is some fatherly advice from an IT old-timer. If you want to go the distance in IT, you need to watch the Healthy Software Developer videos that Jayme Edwards has produced for the mental health of the IT community. Jayme Edwards has produced a huge number of short videos that deal with all of the people-problems you will likely encounter in your IT career. More importantly, Jayme Edwards will also help you to understand your own tendencies to descend into self-destructive behaviors and thought patterns.
Jayme Edwards' The Healthy Software Developer YouTube Home Page:
https://www.youtube.com/c/JaymeEdwardsMedia/featured
Jayme Edwards' The Healthy Software Developer YouTube videos:
https://www.youtube.com/c/JaymeEdwardsMedia/videos
Everything Old is New Again
I only wish that these videos were available when my son first started out and that they were also available to me back in 1979 when I first started in IT. In fact, these videos are timeless because people-problems ultimately stem from human nature, and human nature does not change with time. For example, when I first transitioned into IT from geophysics, I used to talk to the old-timers about the good old days of IT back in the 1950s. They told me that when the operators began their shift on an old-time 1950s vacuum tube computer, the first thing they did was to crank up the voltage on the vacuum tubes to burn out the tubes that were on their last legs. Then they would replace the burned-out tubes to start the day with a fresh machine.
Figure 1 – In the 1950s, mainframe computers contained thousands of vacuum tubes that had to be constantly replaced as they burned out.
The UNIVAC I first came out in 1951 and was 25 feet by 50 feet in size. It contained 5,600 vacuum tubes, 18,000 crystal diodes and 300 electromechanical relays with a total memory of 12 KB.
Figure 2 – The UNIVAC I was very impressive on the outside.
Figure 3 – But the UNIVAC I was a little less impressive on the inside.
Figure 4 – Prior to 1955, huge mercury delay lines built from tubes of mercury that were about 3 inches long were used to store bits of computer memory. A single mercury delay line could store about 18 bits of computer memory as a series of sound waves that were continuously refreshed by quartz piezoelectric transducers at each end of the tube.
In 1955 magnetic core memory came along, and used tiny magnetic rings called "cores" to store bits. Four little wires had to be threaded by hand through each little core in order to store a single bit, so although magnetic core memory was a lot cheaper and smaller than mercury delay lines, it was still very expensive and took up lots of space.
Figure 5 – Magnetic core memory arrived in 1955 and used a little ring of magnetic material, known as a core, to store a bit. Each little core had to be threaded by hand with 4 wires to store a single bit.
Figure 6 – Magnetic core memory was a big improvement over mercury delay lines, but it was still hugely expensive and took up a great deal of space within a computer.
Figure 7 – Finally in the early 1970s inexpensive semiconductor memory chips came along that made computer memory small and cheap.
They also told me about programming the plugboards of electromechanical Unit Record Processing machines back in the 1950s by physically rewiring the plugboards. The Unit Record Processing machines would then process hundreds of punch cards per minute by routing the punch cards from machine to machine in processing streams.
Figure 8 – In the 1950s, Unit Record Processing machines like this card sorter were programmed by physically rewiring a plugboard.
Figure 9 – The plugboard for a Unit Record Processing machine.
As you can see, IT technology was pretty primitive back in the 1950s, 1960s and the 1970s. But despite the primitive IT technology of the day, these old-timers also told me about many of the people-problems that they encountered back then too. And these old-timer people-problem stories sounded very familiar to me. In fact, most of the old-timer stories that I heard back in the 1980s started out after our current IT management made some new process changes. That's when I would hear something like, "Oh, we tried that back in 1955 and it made a huge mess...". So when listening to one of Jayme Edwards' videos, I frequently find myself recalling similar personal situations that I experienced back in the 1980s or similar situations from the 1950s that the old-timers had warned me about. Hardware and software may dramatically change with time, but the people-problems do not. After all, that is why people study history.
How To Go the Distance
Jayme Edwards stresses the importance of taking healthy measures so that you do not get burned out by IT. There are many things that you can do to prevent IT burn-out. Here is a good example:
Why Do So Many Programmers Lose Hope?
https://www.youtube.com/watch?v=NdA6aQR-s4U
Now I really enjoyed my IT career that spanned many decades, but having been around the block a few times, I would like to offer a little advice to those just starting out in IT, and that is to be sure to pace yourself for the long haul. You really need to dial it back a bit to go the distance. Now I don't want this to be seen as a negative posting about careers in IT, but I personally have seen way too many young bright IT professionals burn out due to an overexposure to stress and long hours, and that is a shame. So dialing it back a bit should be seen as a positive recommendation. And you have to get over thinking that dialing it back to a tolerable long-term level makes you a lazy worthless person. In fact, dialing it back a little will give you the opportunity to be a little more creative and introspective in your IT work, and maybe actually come up with something really neat in your IT career.
This all became evident to me back in 1979 when I transitioned from being a class 9 exploration geophysicist in one of Amoco's exploration departments to become a class 9 IT professional in Amoco's IT department. One very scary Monday morning, I was conducted to my new office cubicle in Amoco’s IT department, and I immediately found myself surrounded by a large number of very strange IT people, all scurrying about in a near state of panic, like the characters in Alice in Wonderland. After nearly 40 years in the IT departments of several major corporations, I can now state with confidence that most corporate IT departments can best be described as “frantic” in nature. This new IT job was a totally alien experience for me, and I immediately thought that I had just made a very dreadful mistake. Granted, I had been programming geophysical models for my thesis and for oil companies ever since taking a basic FORTRAN course back in 1972, but that was the full extent of my academic credentials in computer science. I immediately noticed some glaring differences between my two class 9 jobs in the same corporation. As a class 9 geophysicist, I had an enclosed office on the 52nd floor of the Amoco Building in downtown Chicago, with a door that actually locked, and a nice view of the north side of the Chicago Loop and Lake Michigan. With my new class 9 IT job at Amoco I moved down to the low-rent district of the Amoco Building on the 10th floor where the IT department was located to a cubicle with walls that did not provide very much privacy. Only class 11 and 12 IT professionals had relatively secluded cubicles with walls that offered some degree of privacy. Later I learned that you had to be a class 13 IT Manager, like my new boss, to get an enclosed office like I had back up on the 52nd floor. I also noticed that the stress levels of this new IT job had increased tremendously over my previous job as an exploration geophysicist. As a young geophysicist, I was mainly processing seismic data on computers for the more experienced geophysicists to interpret and to plan where to drill the next exploration wells. Sure there was some level of time-urgency because we had to drill a certain number of exploration wells each year to maintain our drilling concessions with foreign governments, but still, work proceeded at a rather manageable pace, allowing us ample time to play with the processing parameters of the software used to process the seismic data into seismic sections.
Figure 10 - Prior to becoming an IT professional, I was mainly using software to process seismic data into seismic sections that could be used to locate exploration wells.
However, the moment I became an IT professional, all of that changed. Suddenly, everything I was supposed to do became a frantic ASAP effort. It is very difficult to do quality work when everything you are supposed to do is ASAP. Projects would come and go, but they were always time-urgent and very stressful, to the point that it affected the quality of the work that was done. It seemed that there was always the temptation to simply slap something into Production to hit an arbitrary deadline, ready or not, and many times we were forced to succumb to that temptation. This became more evident to me when I moved from Applications Development to Middleware Operations, and I had to then live with the sins of pushing software into Production before it was quite ready for primetime. In recent decades, I have also noticed a tendency to hastily bring IT projects in through heroic efforts of breakneck activity, and for IT Management to then act as if that were actually a good thing after the project was completed! When I first transitioned into IT, I also noticed that I was treated a bit more like a high-paid clerk than a highly trained professional, mainly because of the time-pressures of getting things done. One rarely had time to properly think things through. I seriously doubt that most business professionals would want to hurry their surgeons along while under the knife, but that is not so for their IT support professionals.
You might wonder why I did not immediately run back to exploration geophysics in a panic. There certainly were enough jobs for an exploration geophysicist at the time because we were just experiencing the explosion of oil prices resulting from the 1979 Iranian Revolution. However, my wife and I were both from the Chicago area, and we wanted to stay there. In fact, I had just left a really great job with Shell in Houston to come to Amoco's exploration department in Chicago for that very reason. However, when it was announced about six months after my arrival at Amoco that Amoco was moving the Chicago exploration department to Houston, I think the Chief Geophysicist who had just hired me felt guilty, and he found me a job in Amoco's IT department so that we could stay in Chicago. So I was determined to stick it out for a while in IT until something better might come along. However, after a few months in Amoco's IT department, I began to become intrigued. It seemed as though these strange IT people had actually created their own little simulated universe, that seemingly, I could explore on my own. It also seemed to me that my new IT coworkers were struggling because they did not have a theoretical framework from which to work from like I had had in Amoco's exploration department. That is when I started working on softwarephysics. I figured that if you could apply physics to geology; why not apply physics to software? I then began reading the IT trade rags, to see if anybody else was doing similar research, and it seemed as though nobody else on the planet was thinking along those lines, and that raised my level of interest in doing so even higher.
A Final Note
Although I may have spent the very first 25 years of my career working for oil companies, as a geophysicist by training, I am now very much concerned with the effects of climate change. Even if you are only a very young IT professional, climate change will likely have a dominant effect on the rest of your life and the rest of your IT career in the future. Climate change will most likely determine where you work, how you live, what you eat, what you drink and under what kind of government you live. For more on that, please see This Message on Climate Change Was Brought to You by SOFTWARE and Last Call for Carbon-Based Intelligence on Planet Earth. There are many more softwarephysics postings in this blog on how software may shape the rest of your life in the future. All of my postings on softwarephysics are available and are sorted by year via the links in the upper right-hand corner of each posting. The oldest postings deal mainly with explaining how softwarephysics can help you with your job as an IT professional. The newer postings deal more with how softwarephysics can be of help with some of the Big Problems, like the origin of carbon-based life and the future of Intelligence in our Universe.
Comments are welcome at scj333@sbcglobal.net
To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/
Regards,
Steve Johnston
No comments:
Post a Comment