My dad is an engineer - the mechanical variety, not the software variety. Before he did that he also did stints as a mechanic and a carpenter. A smart guy, but also very talented when it comes to building and fixing (as long as it doesn't involve electricity, but that's another story). Even at 60 he's still out building fences, sheds and decks. When my brothers and I were young he did his best to teach us the tools of his trade, so that should we ever find ourselves needing to fix or build something, we'd have the skills to do it. Ok, so he mostly failed with me... but I did learn some important things along the way, and believe it or not they've actually helped me become a better developer and a better entrepreneur.

So here's some of the lessons I learned from a tradie that can even help a techie.

Lesson One: Measure Twice, Cut Once.

Cutting wood is a one time deal. Once it's cut, it can't be un-cut. It's therefore critical to always be sure of every cut you make. Even when you're sure you got it right, measure it again anyway. It's cheaper and easier to check your measurements than it is to have to start over because of a simple avoidable mistake.

Building a product is pretty much the same deal. You wouldn't build a bookshelf without measuring the space where it needs to fit. You also shouldn't build a product without testing if anyone even needs it. It's been said a thousand times, so I don't need to go over that part again. But one thing that isn't often mentioned is that your product is really a set of features, just as your bookshelf is a set of shelves. Each feature needs to be treated carefully and measured against the intended audience to ensure it fits. It's not only important to get that feedback at the start of a project, it's critical to get feedback throughout the process as you continue development. It's far better to do that than it is to wait until the end to find your latest great idea sucks.

Lesson Two: It's harder to paint it once it's up.

We have some guys building a pergola at our house at the moment. The guy painting it turned up to the job after the whole thing was already built. He pointed out that he would've gotten a better result AND taken 1/10th of the time if they'd gotten him to paint the wood whilst it was still on the ground. They could then build the pergola and done a few quick touch-ups afterwards. Not only is it slower and harder to paint the finished product, it can result in to hard-to-paint areas that don't get the proper treatment, and worst of all can make a mess of anything unfortunate enough to be under the thing being painted.

In product development, it's all too easy to forget about the design and UI, leaving the designer to just "tidy it up later". But it can often lead to a situation where a designer is forced to rework HTML or server side code in order to produce an interface that makes sense to the end user. In the worst cases it may not be possible to retrofit some required functionality, leaving you with a slightly imperfect result. User centered design is about building an interface that works for the user FIRST and then constructing the application to support that design. By building the software first and leaving the design to last, you end up making a lot more work for yourself and end up with a potentially inferior finish as a result. UX should be an ongoing process, not something that's just left until the last minute.

Lesson Three: Always keep your project and your workspace clean.

Working in a messy environment guarantees that your project will end in a mess as well. You can't get a good finish on a paint job if there is sawdust everywhere, you can't put an engine back together if all your tools are covered in grease and you'll never find that screwdriver if you don't put your tools away when you finish with them. Any tradesperson will tell you that it's critical to the quality of a job to always be working in a clean environment. Not only do you spend less time looking for misplaced tools, but mess can only ever lead to more mess.

Every programmer has left mess behind in their code. Plenty of coders know of the term "code debt", it's really just the developer's version of a leaving a messy work area. If you create a mess in your source, not only does it make it harder to find bugs, it makes it easier to make more mess in future. You'll eventually need to clean it up, and it's quicker and easier to clean it as you go than it is to come back to it later (especially if you have to clean someone elses mess before you start your own work!). Any coder knows the feeling of dread when you step into someone else code and realize they've left you with a hideous knot of spaghetti to sort out. A little time spent now will save you a lot of time later.

Lesson Four: Always use the right tool for the job (also don't be cheap with your tools).

One of the main reasons for screwing up a job is by using the wrong tool for the job. Using a claw hammer when you should be using a rubber mallet. Using a rip saw when you should be using a tenon saw. Using nails when you should be using screws. It's obvious, but so many people do it anyway; using the wrong tool will almost always end in disaster. Spend the money and get yourself the right tool the first time.

It's often the fault of someone in management, but us developers need to take responsibility for it too. Using a 6 year old laptop will, without doubt, result in working slower. Being too cheap to pay for that $10 text editor and using a crappy one instead want won't help you either. You may feel like you're saving money today, but it will cost you a lot more money in the long run. Skimping on hosting to save a few bucks isn't going to help you win customers. Worst of all, pirating software that helps you make money for yourself is just plain wrong... stop doing it. Find out what tools you need to get the best result for your project, and then hand over the cash to get it (unless it's open source in which case - high five!). When running a startup it's particularly challenging to save money. Don't spend money unless you need to, but if you need to spend it, get the best.

Lesson Five: If all else fails, get a bigger hammer.

Sometimes you need to know when you're stuck. Sometimes that bolt isn't going to budge no matter how much you lean on it. Sometimes that nail isn't going in no matter how hard you hit it. Sometimes all the hard work or finesse in the world won't help you. Sometimes you just need a bloody big hammer.

As a founder of 2 startups, I've often reached the point where I should've just called in some help. But instead I struggled on, I read through manuals, I watched screencasts and read blog posts. Then I woke up and realized, no matter what I do, there's always going to be someone better at it than me. We currently have 2 awesome JS developers working with us, and they're doing a better job than we ever could. There are so many great tools for collaborating with remote teams, there's really no excuse not to just get the right people working with you, wherever they happen to be. Sometimes you just need to suck it up and get out the big hammer.

As an entrepreneur living in a thriving community of developers and designers, it's often a little bit like living in a petrie dish. All of the ideas we get tend to be off people just like ourselves. It's great once in a while to stop and take a look at some of the more traditional professions and see what lessons we can learn from people who've been doing what they do for a whole lot longer than us. Regardless of how smart we think we are, there's always something to be learned by talented people, no matter what their skills may be.