Still like coding

I’ve been on both sides of the employment fence. I’ve been an employee at a startup, a software company and a telecommunications company. I’m currently working for myself. Of all the activities, I still like coding. Because it allows me to solve problems of a nature that’s programmatically solvable.

Customer service

I’ve worked with customer service officers. They are the front-line of the business, and they tell me how my software is working. Is the customer having problems with logging in? Or with downloading transactional records?

Now, I talk directly with customers. They tell me this part is good, or that part is funny. They ask me questions, and I answer them (whether it’s directly a programming problem or not).

Sales

I’ve talked with sales people, and they’re driven and friendly and outspoken. And they tell me what their clients and customers want, because the customers sometimes talk directly with the sales people instead of the customer service officers. Yay me for multiple channels of input.

Sales people want to know sales figures, monthly commission reports and revenue numbers. Well, specific to their own targets anyway.

Now, I keep track of my own revenue and sales. Let me tell you, it’s very sobering.

Marketing and Product

Frankly speaking, everything is integrated into the main sales channel. But marketing and product creation are related enough.

Imagine this. There are people hired to come up with new products for a company to sell (product managers). And people hired to convey the benefits of having said products to the consumers and customers (marketers). And people hired to sell these new products (sales people). And people hired to make sure customers are happy with their purchase (customer service).

Everything is linked.

The mish-mash

As a one-man show, I handle everything. I do market research to see if there’s actually a demand (although I might still create the product). I create the product. I write the sales copy on the sales web page. I upload the information products to the hosting server, and make sure the purchase links are working and correct. I’ve written ad copy (and it’s hard). I’ve written educational, marketing pieces of writing to promote my products. I set sales prices based on the value of what the customer will get (let me tell you, this is ridiculously hard and complicated). I talk with customers. I answer questions (sometimes free of charge). I handle taxes.

Out of all of them, I like the coding part the best. An ebook with a bunch of source code attached is basically a programming guide like one of those For Dummies programming books. I don’t mind writing the source code to teach people how to do something. I don’t even mind writing the ebook to explain some of the concepts, because it’s like a really long extended code comment.

But the other parts are hard. Possibly even distasteful.

However, I recognise the importance of those parts. Every single part is needed. And every part affects every other part.

You don’t know what benefits to convey in your sales copy if you don’t have it in your product. If the market doesn’t want a feature, that feature shouldn’t be in the product.

Of course, everything I’ve said presupposes that your product has a software component. But it really applies to the part that you’re good at and really like doing.

Maybe you’re really good at baking muffins, but you’re not really good at telling people why they should buy your muffins. Or you don’t like the tedium of keeping track of muffin sales. Or packaging your muffins so they really look good (you need to convince people that your product is good, even if it’s really good).

Code like a rockstar

There’s a new course available from Polymath Lectures called “Code Like a Rockstar”. Here’s an excerpt from the course description:

Taught by a successful Google Software Engineer and Computer Science Ph. D., this 5-session online masterclass will teach you expert-level coding techniques and practices which will get your code noticed by companies such as Facebook, Google, Apple, and Microsoft. Acquired over years of writing amazingly stable software at unimaginable scale and complexity, the tips in this course go well beyond the techniques taught in a typical software engineering program.

I think the instructor Michael Barnathan is kinda cool. But you’re welcome to go find out more and make up your own mind. And I don’t get a penny out of this if you sign up.

The course starts on January 7 2012, so you have some time to decide.

Multi-use variables or multiple variables?

So I’ve been working on a software project of mine. I’ll tell you more about it soon enough, but for now, it’s enough to say that I’m writing source code that generates source code.

One thing I’ve noticed is variable declaration. There are 2 extremes.

One variable used multiple times

This is the memory-efficient version. If you need the use of an integer variable, you just declare one variable. For example,

int i;
i = DoSomething() + DoSomethingElse();
DoAlpha(i);
i = DoThis() + DoThat();
DoBeta(i);

That’s just for illustrative purposes. If you’ve written a fair amount of code, I’m sure you can think of better examples. Which are probably (and usually) more elaborate and lengthier.

The drawback to this is that the variable is temporary. As the code continues its execution, previous values stored in that variable are considered to be unimportant to future executions. That’s why the value can be discarded and the variable overwritten.

Multiple variables but one-off use

Then there’s the “declare as many variables as you can (or think you need)” method. For example,

int i1 = DoSomething();
int i2 = DoSomethingElse();
int i3 = DoThis();
int i4 = DoThat();

This has the advantage of keeping the variable values “alive” through that section of code. The drawback is that you use more memory, even if seemingly trivial. I mean, that’s like 12 more bytes of memory (assuming integers still take up 32 bits when you’re reading this). That hardly makes a dent in the computer’s memory space.

The hybrid

The above 2 are extreme cases. What happens when you write code is probably a hybrid, somewhere in between the 2 extremes. For example,

int iSubtotal;
int iTotal;
iSubtotal = DoSomething();
iTotal += iSubtotal;
iSubtotal = DoThis() + DoThat();
DoSomethingElse(iSubtotal);
iTotal += iSubtotal;

You know what you declared those variables for, so you have an idea how many “unique” variables you need. This have the benefits of using the least number of variables (sort of), balanced with keeping the least number of “live” variable values around.

So why am I talking about this?

Auto-generated source code cannot generate hybrids

When you’re writing code, you have one very important advantage: You have context. A program that generates source code, such as a decompiler, does not have that.

When you’re writing code, you make variable decisions such as naming, naming conventions, how many you need and so on.

A decompiler has difficulty making decisions like those, so it has to choose one of the extremes. Typically the multiple variables route, because that’s the safest. All a decompiler can do is detect that a variable is needed, and so writes out the variable declaration in the resulting source code. It cannot decide on whether this part of the code can reuse one of the variables it has already declared (or at least has difficulty doing so).

Ok, so the cat’s out of the bag. I’m writing a decompiler. That’s not exactly true but will suffice for now (I promise I’ll tell you more soon!).

Anyway, that’s what I discovered while working on my software project. I have decided to go the multi-use variable route, because of a human (and programmer) behaviour. A human programmer has difficulty holding on to many separate variables in his head.

When a section of code requires many variables, I tend to try to limit the number of variables I remember in my head. Maybe there’s a pattern. I might remember there’s fFinancialYear1 up to fFinancialYear7. I might decide to refactor the code such that I only need one fFinancialYear floating point variable (assuming the appended numeral makes sense, and not just laziness in naming). I might separate the code section into several sections, so each section has a limited number of variables.

Maybe that’s not how most programmers work, but I find it “friendlier” than having thisIsAnAwesomeClass1 through thisIsAnAwesomeClass20, and I can’t remember which awesome class does which. I tend to work with tighter variable names (where possible and logical), and write code that’s as tight in scope as possible. So the variable values can be discarded, which means I don’t have to keep track of whether that value is still needed, even if the computer doesn’t mind having to keep track of it.

So how do you write your code where variables are concerned?

Colossal computer coding

Jumping fish, lazing cat, right-handed piano keyboard playing and more than 2000 lines of source code written.

You can try to guess what’s the music piece I’m practising on. I’m almost ready… and I’ll have a recording up then.

Podcast: Why programmers write stupid code

Need I tell you, again, how my first recording failed abysmally? Probably not. And here I am, doing another audio recording. Plus the fact that I got a new headset and I want to play with it.

To be honest, I learned a few things. I speak quite fast normally, and when my speech gets into recorded form, my words just slurred together. I just think faster than I can write or speak.

Be clear. That was main goal this time. So I spoke slower and slightly louder. I did some post production work and here it is:

Download mp3 [~ 2:40 minutes ~ 1.22 MB]

Noticed that I haven’t said anything about the subject at hand. Well, here’s a synopsis of the recording.

  • Murder on the Orient Express by Agatha Christie
  • Courting danger in racing simulations
  • Why programmers write stupid code

You’ll have to listen to the recording to find out how all 3 points fit together. For the impatient ones out there who just wants to know the final answer, here’s a hint: First word of first four paragraphs.