Subtitles of the Movie

So, let's back up a little bit. How do we actually get started? Well first, you need an idea. You know, obviously you're going to be doing something. The thing to get to with your ideas is what is the real problem you're trying to solve? And I underlined it and highlighted, real problem; because it's so important to identify that and it's worth your effort to sit and spend some time pondering what is the real problem. Um, often when you have the projects outside of your purview, in other words, perhaps you work for someone or you've been hired to do something and they want you to do, you know, x, y, z and you sit down and you start analyzing it and you realize that's not the real problem that they're trying to solve. That's what they think the problem is, but that's not their real problem. So sometimes, programming and becoming a programmer takes a little bit more than just sitting and coding out some stuff. You really have to delve into what you're trying to solve. So what goes along with that is you,,, have to understand the business that you're working with. Again, if you're working for someone, a company or, you know, as a consultant or something along those lines you've really got to work on understanding what they do. What is their business; what makes them money? In the end that's what this is about. If you have a good grasp on what these people are trying to accomplish then you can answer that question of what is the real problem, and help them. And this is really an important part: help them understand what the real problem is. In other words, help the user understand. You don't just identify it and start working on it. You have to go back to the user and say, Look, here's what I think what were really trying to solve here. And then you have this open dialogue with them and you can move it, you know, move the project forward. So once you've established what are we really trying to do here and understanding where it fits in, in what the business or people do, you've got to figure out what solves the problem. What, if any software solves it. Do you have to custom write stuff? Well, obviously for programming there's some level of customization that's going to go into it. Perhaps there's off-the-shelf stuff available with some minor customization that might work, or open sore software that you can modify a little bit. That's often what happens these days. But sometimes it calls for a completely customized solution and then you have to figure out what's the best technology. Is it Ruby as a programming language and scripting and that type of thing. Or is it a full blown Microsoft dot net desktop application that uses a three-tier kind of technology with a database in the back end and some middle wear somewhere. So you got a client/server kind of thing going on. That's the next step in determining where you go with this. That prevents you from getting really religious about your programming languages. There are people out there that, you know, they say basically Java is the language, or Ruby is the language, or dot net using CLR which is their, their common language reference where you can use different languages to program in dot net. That's the solution. Well, I'm saying, there is no "the" solution. You have to look in each problem, each environment and see what fits in that environment. So again, as a software developer programmer it's not just putting out code. It's seeing where your product that you're producing fits in, how it solves the problem, and if it does it right. And what goes along with that is, does the solution create more problems? I've seen it where you have this great idea and you program the heck out of it and it's a wonderful thing and you put it in a place and realize, oh, there's a whole lot of business processes that I have to change because of the way this works and the, the product that you created. And the issue is with that is it goes back to that first part. You didn't really understand the process, the business processes that you were working with in the first place if it creates more problems. And often, though, you might even understand the business that you're dealing with, or the, the processes that you're dealing with and you still end up with problems cropping up due to how you design the software or how it interacts with a particular other type of software or hardware or something. And you'll have to deal with those because those will pop-up in the middle of your project and you might have to re-orient part of your project to get there. And finally a big thing to answer is how to maintain it. Who's going to maintain it, when are your updates, ah, when are your bug fixes, ah, where's this maintenance going to happen? Is it the responsibility of the company, or are you going to maintain it if you're outside consulting; what kind of costs are involved with it? Again, it's back to that cyclical nature of software development. So those are just a few things to think about with the art of programming. In the art of programming, too, I'm going to delve into a little bit more of the actual act of programming, so throwing some code up and understanding the flexibility that you need to have as a programmer there. If you have any questions you can contact me at alavtc@gmail.com.