A Nail Gun, a Jack Hammer and Herding Cats

Herding Cats

Yup, it’s true. I put a 4 inch nail through my left thumb with the ole’ DuoFast pneumatic framing gun.

Here’s a pic. Don’t worry, it’s not too graphic:

Ever since I was a kid, I wanted to build my own house. Not sure why.

I’d go through the whole process in my mind. From the foundation to the roof, step-by-step, building an imaginary house. Fell asleep many a times with those visions in my head.

My main problem in realizing this dream was money. A bank won’t even consider giving you a mortgage unless you own the land or you’re a licensed builder.

Well, I didn’t own any land and I wasn’t a builder.

But after a lot of searching, I managed to find a company in California that was willing to lend money to do-it-yourself home builders. Yeah, they charged a big chunk of money for the service, but this was really the only way.

It wouldn’t be easy. I had worked a few construction jobs before I joined the military and again throughout college so I had some experience. But this was different. This was a big project.

It turned out to be a long, tough year. Yup, per the terms of the mortgage, it had to be complete in 1 year!

For the most part, it went pretty well. Still, with a big project like a house, there’s so much detail.

And what I learned was that it’s very difficult to get something exactly right the first time you do it.

There is a list of things I wish I had done differently. But, unfortunately, when it comes to house-building, it’s not too easy to go back and make fundamental changes.

So why am I writing about this? Well, aside from getting a chance to show off a really cool picture of a nail through my thumb, I’ve found this to be true in a lot of different areas.

It’s hard to get something right the first time.

As a matter of fact, this is especially true with software programming. Software is usually complex, with a lot of details. It’s very difficult to get all those details right the first time.

But the big difference is that it is easy to go back and change software. You don’t have to jack-hammer a foundation. Just re-write and re-compile.

And when it comes to building an EA, you should expect the same thing. It won’t be right the first time.

I think this fact is actually the best argument for either:

(1) learning MQL, or

(2) using a tool like VTS.

It’s just so much easier to be able to tweak and tune your EA yourself – without having to work with a programmer (like me!).

You know what they say: “Managing programmers is like herding cats”.

Whatever path you choose for your EA development, don’t worry, I doubt you’ll put a nail through your thumb!

NOTE: I took that picture with one of those disposable cameras while I was driving myself to the emergency room. I was back to work about 1 hour later. I’m kinda proud of that! The truth is I got extremely lucky and did not hit any bone.

Truly, it was merely a flesh wound.

Education

EA Bugs? Find Them, Stomp Them, Move Forward

EA Bugs

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
– Brian W. Kernighan

As a long time programmer, I really appreciate that quote.

Brian Kernighan was one the developers of the famous C programming language. He and his partner, Dennis Ritchie, wrote the original UNIX operating system. You might say that code is the basis for the entire internet.

One of my first jobs after graduation was in the college’s business incubator. It was a great opportunity to work with some very talented people. Grad students and professors alike. (Still not sure how I made that cut 🙂 )

Anyway, we were working on a telephone system for commercial aircraft. Remember this was 20 years ago, when a cell phone was the size of a shoe box and its battery lasted about 15 minutes!

We were building the hardware and writing the software at the same time, so there were plenty of opportunities for nasty bugs.

One day I was poking around in the lab trying to nail down an issue. I was testing a few different theories when “Professor V” approached and asked what I was doing.

I explained that I had changed the order of some subroutines because I was trying to solve a boot-up problem.

He politely asked what I expected to happen. I really didn’t know what I expected and I told him that. This was not the right answer.

He sighed and gave me one of those looks. You know, the kind of look that makes you feel like you ran the football in the wrong direction and scored a touchdown for the other team. Not just wrong. Really wrong. Like “How can you possibly not know this?” wrong.

He explained that I had no chance of success using my current approach..

“David, just trying things and seeing what happens won’t cut it. Way too low of a probability of success. You need to be able to explain exactly what should happen and why. And when it doesn’t happen – that’s the source of the problem – that’s where you look”.

I learned that debugging is a little like being a trial lawyer: You never ask a question that you don’t know the answer to.

This was natural for Professor V. He couldn’t even contemplate making changes without having an expected outcome.

I had to learn it that day – and I’ve never forgotten it.

Years later, I’ve applied that lesson, along with many others, to debugging Expert Advisors. I’ve tried to sum up my method in a recent forum post. You can see it here:

http://www.iexpertadvisor.com/forum/messages.aspx?TopicID=230&MessageID=696#post696

NOTE: Here’s another tip for debugging: Explain the problem to someone else. Anyone. They don’t even need to understand what you are saying. But the simple act of verbalizing the problem often helps you find the issue.

The first software bug was a moth!

Education