The Steam of Babbage

tag:blogger.com,1999:blog-8008108632579771211.post-12494081823405442592008-05-08T09:41:00.001-07:002008-05-08T09:52:34.702-07:00The Steam of Babbage<div style="text-align: justify;">Greg asks <a href="http://www.gregandbeth.com/blog/index.php?action=view&id=1102">"What Makes Your Ears Steam?"</a>. I like his example of stupid hippies. But it made me think a little on the way into work this morning and I've come to realize one of the big things that really chaps my ass with people is lazy thinking. This may not seem to be a big deal until you realize that my day job is writing software. Logic, my friends, is how I pay the bills. Content alert! What follows is not gun or rights related. It is geekery at its finest. I will not be offended if you stop reading here. Otherwise, proceed gingerly. Most people aren't familiar with how their computers work. They understand the idea of having programs like Firefox, Office and so on that do different things for them. Send e-mail, write a report, listen to music, games, etc. What most people are far removed from today is how those programs are created. Even the blog you are reading now is a program. The only difference it is running on a computer somewhere else that is sending the results (this page) to your program (the browser) rather than running solely on your machine. Most understand that software is the same thing as a program. I write that software. It's what I've done professionally for over 15 years and what I've been doing overall for over 25 years. So this is something I am very intimately familiar with. But to the layman, it is a deep, dark mystery. Sadly, I can only wish software and programming were as cool and amazing as Hollywood makes it look. Trust me, it isn't. Writing software is extremely detail oriented. If you can't break down a process into its steps, think in terms of abstractions and be able to drill down into figuring out how something works, this isn't a job for you. Software development pays well for that very reason. It's hard. Some people can be taught some of the aspects of it and be functional but they never truly "get it". The ones that do get it are always employed for that very reason. My personal belief is you have to both taught to think in these terms and be wired mentally to accept them. I do believe that there is a certain amount of natural selection involved in a person's success or failure in this. Some people are just naturally able to pick up certain things better than others. We're all like this. For example, I like music a lot. I can appreciate and hear the different rhythms and instruments and enjoy how a piece of music is put together. I can get into it. But I can't reproduce it and the few attempts of my trying to learn to play music have been difficult and mechanical. Perhaps I didn't try hard enough even though I can hear what others have done, I don't have the ability to effortlessly do it on my own either in my head or for real. Your ears will probably thank me for that. Another area is language. I can't pick up another language short of my life depending on it. I've tried that too. Hell, I was forced to. Learned French in school until Grade 10. Was never fluent in it and it never stuck even when I was in the classes. Likewise, I did it by rote and mechanics. I have no innate ability to learn another language. Kind of throws water on my dream of joining the French Foreign Legion especially given I spent 10 years trying to learn French with nothing to show for it beyond "Non parle vous Francais". In contrast, my fiancee and her Mom are fluent in several languages. Some people simply can't grasp mathematical concepts. I'm the opposite. Although rusty and no genius in the math realm, the fundamental principles of math that apply to software I picked up easily and early on. If you can grasp basic algebra, geometry and word problems (which many people absolutely despise and do not get), you possibly have the foundation to be able to write software. So where am I going with this? I work in corporate software development. What you may not know is the vast majority of software written throughout the world is NOT written to be sold to consumers like you and me. It is written by business to support their operations. You never see it. You hear it. All the time. Anytime you're on the phone with a customer service person and you hear the "click, click, click" of a keyboard in the background, odds are good they are using a piece of software bought or written by that business to help them get their job done. So the programs that I write are for specific business needs. In this modern world of web sites and blogs, it means I write programs designed to be used through a web browser. Think of Amazon where you select items, view your shopping cart, fill in forms with your shipping and payment information and submit your order. A little while later, you get an e-mail saying "Here's Your Order Confirmation". All of these things are done by programs and it is essentially what I do. I write the programs that take the forms you fill in and do something with it. Generally, I'll have a requirement from the business that says "We need a program that can do X, Y and Z in the following way using a web browser.". I then go write the programs that make it happen. The irony of this is, despite the fact I am employed writing web-based software, I don't actually write any web pages (such as this blog's page) myself. Instead, I write the pieces that provide the information that the programmers that write the web pages display. I provide the components that do what we call "the heavy lifting". Talking to databases, organizing data into usable information, making our software do things that mimic what the business does. Trying to make these processes understandable and then hook them all together. The thing I do best is automating the tedious. You'd be surprised at the number of otherwise decent programmers who write the same type of code over and over again and not see it as repetitive because the data code X was working with was different from that of code Y. This is extremely commonplace in accessing databases. But if you remove the specifics of the data, you'll see that the behavior and structure of the code between the two is very similar. In software development, we call these "patterns". Over the years, the focus of good software engineering has been to identify these patterns and find ways to capture them and then let them only vary a little bit because of the data or application. I am very good at seeing repetitive behavior in programs and finding ways to automate or simplify them. The end result of this process is what might have been 1000 lines of code repeated across two or three programs becomes 1200 lines of code written once and 30 or 40 lines of code in each program that the programmer actually needs to know. The rest is written for them and hides away all the tedious messiness of compromise that is modern software that they would have otherwise repeated over and over for no good reason. As a result, I am the one who sets overall direction for long-term software devlopment within our team and I provide major pieces of the programs other programmers use to assemble their programs. For those of you in the know, I write "middleware". There are two realities about this job. One, it is a job most people don't want. You aren't writing the web pages that the vice-presidents and the customers see online. The stuff they think is the program really isn't. It's behind the scenes. Unseen, unloved and unknown. Until it breaks (different story then). Otherwise, a life of quiet, ugly anonymity among glamorous fashion models. Who'd want that? For the reason of the other reality of the job. Despite its unsung nature, properly designed and engineered middleware is what drives a business. A reality of corporate software development is 80% of the overall costs of writing a program for internal use is tied up in maintaining that program over its lifetime. Years of studies have shown this. As a result, anything that you can do that cuts down in a significant way on the amount of time, and hence money, needed to modify or change a program over its lifetime is a big deal to a business. And for those who can see through the immediate problems, think towards the future and succeed in doing it right more often than wrong, there is a great deal of opportunity in this area. I've learned over the years that if you can play in that space and show the business results in this area, you'll never starve. I never have. I found my niche and I do fairly well by it. So I get really, really annoyed when I keep seeing programmers doing dumb shit. I'm stunned at the number of programmers who do repetitive stuff over and over (like copying and pasting code) because of either a) they don't see the obvious pattern in front of them or b) it's the way they've always done or c) they don't have time to do it right because of a looming deadline or issue. The first is understandable. Not all developers are equal. Some do things by rote because that's how they've been taught. Give them a working example and they're fine. They can run with it. But they can't see any potential problems with what they are doing. They lack the capacity to look beyond the immediate and abstract it into a better long-term solution. Some can never learn how either. The second is commonplace. You repeat what works. However, like many disciplines, it is very easy to fall into the trap of familiarity. Or, "if it ain't broke, don't fix it.". Alas in software, there are varying degrees of "broke". We'll get to that. Sometimes doing it because it works isn't the best thing in the long term. Which leads to the third item. The third is what really upsets me. The programmer recognizes there is a better way to do something. They see the inherent flaws in what they are doing and often have a way in their mind to do it better. If asked, they'll even tell you what that is. But when you ask them why they aren't doing it, they say they don't have time, no one cares or they just don't want to or feel like it. I cannot stand that type of lazy thinking. It drives me to virtual apopolexy. They see a bad design, acknowledge it, have a solution and yet accept the worse strategy because of short term gain. Whether laziness on their part or because they see the business as not caring and they see their effort as being wasted. Or because the deadline is more important than doing it right. If you take pride in your work, you try to do it right. Even if it is just for yourself. In software, this a very important thing. Often, you might have to come back to make some changes on a program you worked on a year ago. By then, you've forgotten all the details of the program you knew while you last worked on it and have to figure them out all over again. A proper solution versus a half-assed one can save you a lot of aggravation down the road. And a solution the business will thank you for in saved maintenance costs. I follow a simple mantra: "Write for the person who will succeed you. They'll thank you. Sometimes, it might even be you.". In software, a simple application of this mantra is to sit someone down in front of your program who has never seen it and let them figure it roughly what it is supposed to do. If a less-experienced programmer can grasp what your program is doing within 10-15 minutes of casual observation, you're doing it right. It's amazing how you can build an entire career around such simple philosophies. But when others don't subscribe to those views, it is very hard to resist the urge to choke the life out of them. Unfortunately, there is a lot of lazy thinking in the corporate software world and not all of it originates from programmers. That is a much harder nut to crack and can reduce even the most experienced programmer to wishing they were at a bar at that particular moment. Tales for a future post perhaps. Not what you were expecting today. I'm trying to branch out. Welcome to my world!</div>The Armed Canadianhttp://www.blogger.com/profile/09187514314023986067noreply@blogger.com