I’ve been bitten more than once by data imports consuming an unreasonable amount of time in software projects. Here are some lessons.

Know what to expect

The client (or whoever is sourcing the data) will give you poor quality data from disparate sources, and they’ll drip-feed it over a period of way-too-long. Each version will be in a slightly different format. They’ll say “just get started with this” then want a complete re-do with fresh data later. They’ll give you the final copy, then the actual final copy, then the final FINAL copy. Eventually, you’ll get the real actual final renamed FINAL CONFIRMED copy…

Customers want fixed price. Here’s how to make it a fair deal for yourself.

I recently read the tweet-storm below.

It continues with:

Unless you’ve done the job 20 times, and can estimate how long it will take with a high-degree of certainty, fixed-price is suboptimal. Like the over-under in betting, someone wins, and someone loses. And to answer who is more likely to win, the contractor or the employer, you can answer with another question: When was the last time you had a software project come in on-schedule? For clarity, fixed duration contracts are fine: “You pay for…

Unexpected circumstances have meant I’ve done two job hunts in recent months. I usually scribble down a handful of questions to ask or consider prior to each interview. Here they are so I can remember and refine them over time.

1. What does the business do? Who’s the target market? What’s the dream? How big to you want to get etc?
2. How long have you been around? Are you profitable? Have you taken VC? Who are the main people strategically driving the direction of the business?
3. How big’s the dev team? How many people? What roles? Full timers, part timers, contractors…

After Ruby Conf AU, I came away noticing a few common traits of good talks:

Excellent delivery

On stage, you’re not just speaking, you’re performing. Turn the enthusiasm up a few notches from what you’d use in a face-to-face conversation. Don’t just stand behind the podium and read.

A story

Don’t present points. A blog post can do that. Bring some personal anecdotes in, and weave a story out of the information you’re presenting. Relive the emotions you felt at the time. This comes back to the idea of ‘performing’.

Great Tech talks:

Distill the technical idea to the smallest, most basic possible representation. Come up with…

In year 10, my art teacher stopped me.

“Stop! You’re a perfectionist! And perfectionism is a disease!”

Having been praised for my perfectionism all my life, I dismissed her advice. It took more than a decade for me to realise just how right she was.

Perfectionism exists in maths tests and multiple choice comprehensions. It doesn’t exist in real life, and it certainly doesn’t exist in business or software. “Perfect” is the good-enough trade off between countless goals pulling in different directions.

In real life, perfectionism is a disease.

I took my own advice at Ruby Conf and introduced myself to several of the better known speakers. One thing I asked each was: what is the common trait between yourself and others who are ‘famous within the community’?

Interestingly, none thought it was a matter of being significantly smarter, or better at programming. All told me essentially the same thing: it’s a matter of fearlessly and repeatedly putting yourself out there in public, and providing as much value as possible to the community.

Katrina Owen put it most succinctly: “you have to have done something in public that people appreciate”.

In India, one of the top recommendations for young yogis aspiring to enlightenment is “keep the company of the wise”.

I gave up on enlightenment a while ago, but the same applies to any aspiration. Sometimes there’s a tendency — at conferences, meetups, and in the work place— to want to stick to your own crowd. I’m a junior, I should stick with other juniors.

Actively fight that urge. Find the best people. Find the ones with the most wisdom to share. Then pull them off that pedestal, because you should never have put them up there in the first place, and talk to them.

Keep the company of the wise.

I was once told three rules for good writing:

• Stern logic
• Clear connections
• Utter simplicity

The same apply to writing software. Forget design patterns and best practices — they’re a means to an end, not an end in themselves. If your code adheres to these three rules, it’s good code. No matter what anyone says.