When I’ve broken production apps, stakeholders have often asked: “What can we do to ensure this doesn’t happen again?”
The relationship between development speed and bugs looks something like this:
Rushed pace & poor testing means many bugs. Slow down, and at first you’ll drastically reduce bugs. But slow down more, and you begin to bottom out. You can never reach zero.
Breaking prod less means using time, money, and bureaucracy to slide right on an axis of diminishing returns.
Finding the sweet spot requires ongoing collaboration between business and tech. …
I’ve been bitten more than once by data imports consuming an unreasonable amount of time in software projects. Here are some lessons.
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.
After Ruby Conf AU, I came away noticing a few common traits of good talks:
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.
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’.
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:
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.
Software engineer / engineering manager.