Code maturity

A nice blog post for levels of making code work was brought to my attention. Here is a quick reminder cheatlist:

1. Make it work
2. Make it work well
3. Make it work automatically
4. Make it work invisibly

[...] “Good enough” is a programming concept that varies a lot from project to project, but overall it broadly fits into four categories.  Understand which one you’re aiming for and whether it might be useful to try to progress your code to a higher level of “Good enough”.

I have already posted about code quality earlier.

Update: A quoute from Proccessing.org:

The argument is not to avoid continually rewriting, but rather to delay engineering work until it’s appropriate

See also:

• Sexify your source-code by Adam
• About Code, Quality and General Hackability by Andreas
• How to write unmaintainable code  by Roedy
• Software Horror Stories
• Bugs in open source projects by Andrey
• What Castles Can Teach by Matt

5 Marketing Tips For Freelancers

Scott at OPEN Forum has published the following tips

1. Spend some time fixing up your address book
2. Blog about side projects worth talking about
3. Marketing your ideas and your own brand must also happen offline
4. You need to market your greatest works in order to build your network and gain respect
5. Create something that will differentiate your portfolio when the boom returns

Code Quality

Here is a nice list to indicate the intended code quality from Phil Haack:

• Prototype Code – Code used to hash out an idea to see if it’s feasible or as a means of learning a new technology. Often very ugly throwaway code with little attention paid to good design.
• Demo Code – Code used to illustrate a concept, especially in a public setting. Like prototype code, solid design is sometimes sacrificed for clarity, but these sacrifices are deliberate and intentional, which is very important. My jQuery Grid demo above is an example of what I mean.
• Sample Code – Very similar to demo code, the difference being that good design principles should be demonstrated for the code relevant to the concept the sample is demonstrating. Code irrelevant to the core concept might be fine to leave out or have lower quality. For example, if the sample is showing a data access technique, you might still leave out exception handling, caching, etc… since it’s not the goal of the sample to demonstrate those concepts.
• Production Code – Code you’re running your business on, or selling. Should be as high quality as possible given your constraints. Sometimes, shortcuts are taken in the short run (incurring technical debt) with the intention of paying down the debt ASAP.
• Reference Code – This is code that is intended to demonstrate the correct way to build an application and should be almost idealized in its embracement of good design practices.

See also:

• Recklessly Going Into Debt by Chris
• What level programmer are you by Daniel

How’s it going?

The manager walks up to a developer for latest news, how does the poor sap respond?

• It works on my machine
• That’s weird!
• But this was running before…
• Some minor stuff has to be fixed
• This must be a hardware problem
• Someone tinkered with incoming data
• But I didn’t touch that module
• I’m almost finished
• That’s will be done quickly
• You can’t test everything.
• It’s impossible that it will affect the other module
• I remember that I fixed this bug already
• Documentation is being written
• This is not my program
• I had lots of unexpected troubles
• But the specification was always changing
• I thought I found the bug
• This change will be done in 5 minutes
• I’m waiting for the others so I can test
• Aside from the fact it is not working, what is your impression?

Update:

• Howto discourage from working overtime.
• Excuses for installing a game.
• Things you should never say to your boss by Alison