How Do You Like What You've Built?

This happens to me, a lot. I now consider it part of my workflow.

I submit something for testing.

It gets ignored by everyone else.

I keep testing like mad, fixing even the smallest "niggles" that I can find, re-releasing, and, each time, asking for input.

Which I seldom get.

In the end, I say "Fuck it. Let's ship." but I don't do that, until I'm really sure that there's no more bugs to be found (spoiler: There's always more bugs to be found, and they pop up, immediately after I release).

I'm constantly testing my work. It never stops, and the frequency of my testing, has virtually nothing to do with whether or not anyone else tests, or even gives me any feedback.

I use Apple's TestFlight for my team testing. It registers -roughly- how many times the app under test is run by individual team members.

My own testing is always an order of magnitude greater than the next person, and that is just a fraction of how many times I run it in the simulator, before releasing the test build.

I'm not especially upset about that, but I don't spare a lot of sympathy for folks that complain about something after shipping, that they had every chance to catch, beforehand.

But, if they are right, I'll still fix it. I just won't feel very sorry for them.

Perhaps the largest cause of wasted programming time is building things based on what sounds plausibly useful rather than what is actually useful. It's not an easy question to answer, but it needs to be asked constantly to avoid the trap.

Many of us have had the experience of spending an entire weekend feverishly hacking on something that was going to change the world, only to have someone point out a critical flaw in our assumptions as soon as they try it.

This is why scratching your own itch is so effective. If you make something that you actually use every day, you might be on to something. Going from 0 to 1 users is the hardest step.

This is something I call latent product development. Many times, the best solution is not the first one you think of - even though it may be one of many correct solutions.

I have found that the best products and product features have come from latent thinking. Subconsciously pondering the problem and letting the solution arise. An example of this is a solution which comes to you in the shower - I don't know why the shower is such a hotbed for latent ideas to emerge - someone should study that!

What I found most displeasing at large companies is that there's no room for latent product development. Everything is rushed. Even brand new product ideas, once the machine gets a hold of it, gets put on the conveyor belt for new ideas at a predictable and imposed rate.

One such example is my last startup. We had wanted to make it easy for users not on our platform to collaborate. It was a product feature we talked about for a year but nothing ever felt right. Until one morning at 2am while I was sleeping on a recliner at my sister's house in Mali - it came to me. It also turns out that this feature was the first feature we would relaunch after being acquired by Western Digital.

These intangible factors are why I still love software dev over 20 years in.

The sixth sense of, "this still can't be right" and really getting into the intellectual muck to find out what the proper abstraction should be while also balancing what is needed for great UX.

It still keeps me up at night (or more specifically, from getting deep sleep!) from time to time. And then when you crack it...such a rush.

I've honestly come to find flaws in most of what I build over time. This isn't to say that the products I build or the code I write is inherently bad, it's that I keep learning new ways to be better over time and deadlines always necessitate making trade-offs.

The truly great moments though, are when you go back to a "tried and trusted" solution to a problem. In the past I might have used a more complex algorithm or framework, but my experience tells me to keep it simple and build on something I know is more applicable.

Those are the moments when mere knowledge is surpassed by experience and that's when I truly feel proud of what I've built.

I have a friend who’s a scholar of history at Oxford. They do a lot of 1-on-1 tutoring with students, and he makes his students stand and read out their essays to him.

He likes to stop them halfway through and ask … “does that sound right to you?”. He does it so much that its become a running joke amongst his students.

I love the question. It tugs ever so subtly at your sense of pride in your work. I’m tempted to start using it myself.

I don't think this phrase has ever been uttered by a Facebook programmer.

Rule #17: "Only forward meaningful data at every layer of a design, as it often naturally ensures a feasible convergent behavior."

Most people only learn this after failing hard with a "big data" project... =3

Maybe I’m misinterpreting the article. But I fail to see how the question (or leaving a conversation in the middle) added anything to the solution. Their colleague executed despite a problematic conversation.

Nice little post!