Being a programmer is hard; running a business is even harder. Here is an accumulation of information and further reading to help you with your business. Note: most of the information is focused on software / web development but there is some general business information.
Great sample website contract http://stuffandnonsense.co.uk/content/dl/2010/05/11/contract-killer-2nd-hit.txt
Good Versus Great
Write down the three biggest changes you would like to see made in your project team, business unit, or company. If you were in charge, what specific actions would you take to make these changes? Have you voiced any of these suggestions to your boss in a constructive manner?
Think about what keeps you from speaking up at work. Write down these impediments, and discuss them with friend and loved ones.
Write down your values. Write down ethical boundaries that you promise yourself you will not cross. Discuss these values and boundaries with friends and loved ones.
Shorter Deliverables are Better
It’s important for developers to remember, especially with non-technical clients, that progress you can visualize with a user interface is often the only thing that matters to the client. Non-technical clients don’t care that you pushed out 500 lines of code this week, or that you had a hard time interacting with some web service; the only metric by which they can gauge progress is what they can see on the screen. That’s not to say that doing good work on the back-end is irrelevant, but rather that you need to make all this good work tangible in the eyes of the client.
Which is why I like weekly or bi-weekly deliverables. Anything shorter than that often puts the developer in a hard place: maybe they get stuck doing back-end work for two days and don’t have time to finish the interface, so they have nothing to show the client.
Cost of the Solution
There’s the known cost in terms of what we’d spend to solve a problem. That’s the cost of solution. But we do better comparing it to the cost of the problem to get an idea of whether we actually want to invest in the solution. Sometimes the solution costs more than the problem. That’s a pill perfectionists swallow, a lot. So when we face a recurring manual task we may first calculate how much that task, the problem, costs us. And then we look at how much automating the task, the solution, would cost. A task that requires two minutes every week may not be worth spending several tens of thousands of dollars to automate.
And then there’s cost in terms of comparative cost. Personally, I’ve found myself saying “we shouldn’t do this because it’s expensive” a lot. That “expensive” has rarely meant high-priced. It had to be seen as comparative, “more expensive.” In a code scenario let’s think of solving a styling problem by inserting extra markup instead of accepting additional complexity in the style sheet (although you already know that getting the markup right is important). That solution could turn out expensive not absolutely, as inserting that extra markup might only require a few seconds, but relatively because it would require every team member to know about the new constraint, because it would require being done many more times, and because overall it would be more work.
Christoph Rumpel this is a good one about being a developer
This page contains information I gathered and thought were very useful. See more notes on programming.
Just to let you know, this page was last updated Monday, Mar 30 20