Skip to main content

Posts

Showing posts from November, 2004

Time, money, people...

For those in development, there is the pervading sense that you have to perform really well to get ahead and to do that requires very little sleep and lots of time in the office. Traditionally, the game industry has been this way, but more and more software development firms are doing this...to their detriment. It is a well-known fact that very few developers last more than 5 years in the game development industry. The single most common cause for a developer to leave a game development firm is that they are spent, worn out, burned out (whichever term you are familiar with). The problem is NOT tight schedules. The problem is that developers everywhere seem to think they have no control over the schedule. However, some developers have it figured out: Break the schedule into three categories and allow the person who wants the job done to define two of them. The categories are time, money, and people. Every project is measurable in the amount of time it will take, how much mo

Stay on task

A good way to stay on task is to set a task list. For instance, if you are working on two simultaneous projects (generally a bad idea unless one is a brand new project), splitting your day into two parts is the best way to go. The first half of the day (before lunch) is spent on the priority project and the second half of the day is spent on the lower priority project. There is a two-fold reason for this: 1) People are better able to think in the morning regardless if they think they don't. Well, more real work tends to get done in the morning. After lunch, the food settles and drowsiness settles in for the rest of the day. I know people who take a late lunch for this very reason. 2) You want to look professional by doing higher priority items first. It makes you seem like you have it together. Most people really have no clue what they are doing. I tend to do the odds-and-ends tasks that build up to the main high-priority item. When people review my work they wond

Dishonest business...

You know the "Yellow Pages"? I am sorely tempted to report them to the Better Business Bureau (the BBB) for having dishonest business practices. I just got a call from their obviously Indian outsourced division and got some of the slickest advertising thrown at me. If I had not been paying attention to what I was doing and it had been at 8 a.m. instead of 10 a.m., I would have likely stepped into some very difficult to opt-out of program. As it was, I was deeply in thought about how to optimize cubic bezier curves when the phone rang. Basically, the conversation went like this: Me (groggily - I don't do mornings): Hello? Woman: Hello, I am......and I am verifying your current Yellow Pages listing. Me: Okay. Woman: You are..., your business is..., your business location is... Me: Yes, yes, yes. Woman: Your free listing in the Yellow Pages has been updated with the latest information and you are getting a free 14 day advertisement on our website. Pleas

Setting a goal

One of the first things to do in software development is to set a goal. Simply saying, "I want to learn C/C++/VB/whatever" is not good enough. You will learn the syntax and the language, sure, but you will feel like you have learned nothing. Instead, what you want to say is, "I want to advance my skills to build an application that I can use from my computer to blog with without having to go to Blogger to do so." Assuming you have knowledge of how to go about writing such a program, even if you do not fully understand the syntax of the language you use, you will succeed in making the program and learn new things along the way. Now, however, let us say that you have completed said application and want to sell it. In order to sell the application, you need to simply say more than, "I want to sell this really amazing application." You are likely to enter into what I call "overhype mode" where you overhype the product beyond what it can r

Floating-point

I have traditionally avoided floating point arithmetic because it is a royal pain to work with. Those who have know what I am talking about. What is much more frustrating is if users see floating-point rounding as some sort of fatal error. Take, for instance, 6.934376572E-150. Programmers and people who understand the limitations of floating-point know that a number like that is simply 0. To an accountant or banker or a regular PC user, that number has an E in it, so it must be an error. What could I possibly have done wrong this time? Making sure your users do not see floating point errors is a huge issue and difficult to solve. One user will want two digits of precision all the time, others won't care if zeroes are chopped off, and still others want to have the option to see the floating-point errors. Given that most users (80/20 rule of thumb) will want zeroes chopped off, a simple bit of code in C/C++ to convert a floating-point number to a truncated floating-point n

Optimizations

On one of the mass mailing lists that I moderate (people subscribe to them - not SPAM), I constantly see people asking about whether something like memset() is faster than assigning variables the values directly. These are trivial optimizations and usually someone says so. Given that today's computers are averaging around 2GHz in the user realm, does is not seem odd that such discussions are still going on? What is typically happening is that the person read somewhere that optimizations for performance are really important. The person ends up trying to optimize code that simply doesn't need optimization or they are trying to optimize the code because they used the wrong algorithm for the given situation. The only traditional bottleneck where optimizing code to extremes was where the algorithm was the correct one to use and just happened to be performance intensive. This happened particularly when developing games. Of course, if you were developing games, you were in a

Hmm...

The latest StrongBad e-mail (#117) references #173. Feel free to click here: http://www.homestarrunner.com/sbemail173.html To get them to come up with one of those nifty pages like this: http://www.homestarrunner.com/sbemail100.html Hmm...fresh blueberry pancakes sound good right now. No syrup or butter. Just the pancake and a good tall glass of milk.

Look mom! I can be a terrorist!

Probably the most disturbing tiny bit of SPAM to hit my in-box that I have seen consists of some spammer advertising weapons in e-mail. Hmm...let's see...I've got a few spare bucks or so and I have nothing better to do with my life than go become a professional terrorist. (Hopefully you caught the oxymoron in that last sentence). Really. These people have to be dead to themselves to realize that blowing themselves and a bunch of other people up is a complete waste of everyone's time and not an artform. We could all be writing programs that benefit society or something like that instead. I mean, I have a task list of at least 500 things that would keep every terrorist occupied for the next couple centuries. They would not have time to do anything else but write computer code. Besides, coding is fun. Programmers know this to be true. There are very few thrills on earth that get the adrenaline going than a late-night debugging session (roller coasters come close). Nothin

Brain Jam...

The person Google just hired is not a real programmer and they missed the one who was. Oops. http://www.google.com/codejam/ Why do I say this? Programmers who code really fast generally lose track of what they are doing. When CubicleSoft writes code, the code has already been written...in our heads with ideas on paper that fire off the memories of the code. Real programmers can visualize code coming together as someone rattles off requirements. Not just big generalized blocks of code but the entire thing line-by-line. They wake up at crazy hours of the morning with the realization that they forgot one important line of code and can't sleep until they fix it. When a company gets their hands on a real programmer, everyone knows it. Real programmers can determine exactly how long something will take to develop to the hour and then produce it on time generally with only a couple bugs that are worked out in the QA process. Product managers love these type of people. Or they sh

Hmm...I wonder...

I just found out that the republicans now have a majority in both the house and senate and governor races. This is particularly unusual and actually is a HUGE plus for software developers. In fact, this is the best possible scenario that could have ever been created. A decidedly complete republican majority has, more or less, meant better economics in the short term. Now, while the President has no effect on the economy, the government can play a small role in improving it for a short time (a couple years). Here is what I mean by this: Microsoft Windows has a window of opportunity for Longhorn that they can't afford to pass up. Even if it means releasing it early in late 2005. I have consistently predicted that Linux could take on Longhorn and take out Microsoft if the developers bothered to work on a little thing called usability testing. However, my predictions depend on an early 2006 official release and mid-2005 beta for Windows developers. Assuming pretty de

Finally works...

Took forever, but just for the curious, my new DLL stuff finally works. Pretty cool actually, but since it is proprietary, I can't share exactly how it works. Just know this - it involves lots of macros and plenty of pre-compiler abuse and works great under both Borland C++ Builder and MSVC++ .NET 2003. I'm so proud I want to hug myself. But I won't because that would look weird.

"DLL Hell"

Today I experienced what every Windows programmer experiences when interacting with DLLs - only on a much grander scale. What I am talking about is "DLL Hell." The results of these efforts caused me to have 23 programs open along with 50 unique files. Over the past week I have been working on huge modifications to some core library code. This code is fairly proprietary, but basically what I was striving for is perhaps the most unique approach to interacting with DLLs. As many people know, I already live and thrive in macro hell. For instance, my most evil macro to date is basically unreadable and 335 characters long...and on one line. Anyway, as I said, I have come up with a really creative and unique way to load in a DLL. The way this works is to simulate delay-loading with the option of not running into the issue of crashing if it fails to load for whatever reason. This feature is actually useful where plug-ins are concerned. The other issue is that I needed application