This post originated from an RSS feed registered with Python Buzz
by Rod Hyde.
Original Post: How to program (with acronyms)
Feed Title: The landscape.
Feed URL: http://www.bloglines.com/blog/RodHyde/rss
Feed Description: The technical landscape through the eyes of an occasional indie games programmer who now uses Python as his language of choice.
I'm old. Old enough to need a nap when I get home. But being old and cranky means that I can be, well, old and cranky. Did you know that most books about programming are full of crap? Did you know that you can tell when someone has only ever programmed in one language or on one platform? I am more than happy to throw up my hands and say that I don't have all the answers, but here's what works for me.
If you're trying to get things done, don't go off and write amazing pieces of code that abstract out everything that you're doing into an amorphous lump of jelly that might be useful in your next project. Don't write one framework to rule them all. Write something that does the job. No more. No less.
2 - DRY - Don't repeat yourself
When you do find that you're repeating yourself, that's when you take the code that you've written and abstract it out a bit. Take the pieces that are the same and put them together. Take the pieces that are different and put them somewhere else. And, if tempted to write one framework to rule them all, remember rule 1.
3 - JFDI - Just fscking do it
Really. Look at what you need to do. The end goal. Write it down on a piece of paper. There are often several ways of getting there. Pick one that you know and make a start. If you don't know any way of getting there, then start writing down how you might get there. Then turn some of that thought into code. Don't worry if it's not elegant. Don't worry if it's not object oriented. Don't worry if it doesn't have pages and pages of specification attached to it. That's not the point. The point is that you need it to do what it is supposed to do. I'd rather see one piece of inelegant, unmaintainable spaghetti crap that actually works, than 1000 pieces of beautifully sculpted code that fail to get the job done. If you get the interfaces right and the tests right then you can come back and make it work better later.
4 - SIB - Seeing is believing
I've been in too many meetings where people have said that something can't be done, or it'll take too long, or we don't do that round here, or the software doesn't work like that. Well, words are cheap. I've found that taking people aside and showing them a demonstration (could be a prototype, could be something that shows why their belief in the software's behaviour is unfounded) speaks volumes. Want to show that something is possible? Write a demo using your favourite language. Want to show that the software breaks down under a certain load? Write a demo and show them the error logs.
5 - IFAD - Ignore fads and dogma
I see a lot of fine, bright graduates. Some of them will even turn into fine, bright employees. But even the bright ones seem to be labouring under the misapprehension that some particular style or means of programming (usually object oriented, usually perverted by Java) is the only way to do things. That's like the argument that says my country is the best in the world, coming from a person who has never left their country.
There are many programming fads, language fads, framework fads, design fads, architecture fads, management fads and project management fads. Guess what. None of them matter unless they get the job done. So, pay attention to them, because sometimes they have useful aspects, but don't let them take over how you do things. There are no silver bullets.
6 - ASQ - Ask stupid questions
...because no one else will. I think I've carved out a whole evolutionary niche for myself as the guy who gets things done. It's just not true though. In my mind I'm the annoying guy who asks stupid questions. But people are so keen not to be seen as stupid that they will assume that the person who designed the system has covered everything. That's rarely true. And don't get sidetracked by people telling you that you can't ask questions unless you have a solution. That's bollocks. What are they going to say next? You can't listen to music because you can't play it? You can't enjoy food because you're not a chef?
Previous Topic
