How Do You Like What You've Built?
morrisbrodersen.de
morrisbrodersen.de
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.
I’m not really a fan of the MVP model, as I think it results in substandard product, but it is actually a very good way to get end-user feedback.
The main issue, is the same as with controlled testing: There’s often a dearth of useful feedback.
With shipping product, people just vote with their feet. They don’t use it, and won’t tell you why. In the case of the stuff I write, we deliberately keep as little information as possible, about our users, so soliciting feedback is a challenge.
I spend a lot of time, “reading tea leaves,” so to speak. I try to watch people use my stuff “in the wild.” I find focus groups and usability testing to be almost worthless.
The surprise is usually the mental model that users develop. It can sometimes be radically different from the actual way the software works. That’s not always a bad thing, though. Sometimes, we should “lean into” an inaccurate model, if it reinforces the usefulness of our work.
I do write a bit about that kind of thing, here: https://littlegreenviper.com/the-road-most-traveled-by/#chao...
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.
For some of us, we will not deeply use the industry-specific line-of-business things we've been asked to work on and won't have a good, calibrated opinion. In these situations, developers without the industry knowledge should get that validation before making those kinds of decisions.
https://news.ycombinator.com/item?id=42414911
----
Write code and experiment instead of talking and planning
I want to have a chat with the computer in its own language right from the start. "But your attempts will lead you on so many fruitless avenues!" the committee heads admonish me. "You will waste so much time! Let's have a grand plan and write the perfect solution right from the start, ehh?"
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.
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.
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.
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 anyone other than me, reads them, or even give's a rodent's backend about it, but I do it, to learn.
Just a little while ago, I wrote a short series on customizing SwiftUI Charts[1].
What I learned, made such a difference, that I immediately rewrote a dashboard app to use the new techniques. It's working great.
[0] https://littlegreenviper.com/miscellany/
[1] https://littlegreenviper.com/series/swiftui-charts-gestures/
Most people only learn this after failing hard with a "big data" project... =3
Rule #6: "Perspective is earned, and cannot be given freely."
Besides, we all know truisms tend to be terrible wit... Best of luck =3
As a middle manager myself though, I understand why you jumped to that conclusion. Because this is an example of highly efficient behavior in a system of imperfect humans, which all large teams are. Typically in a large cross-functional teams, engineers are not incentivized to question product requirements because it's not technically their job. But in practice, engineers closest to the problem are best positioned to recognize requirement flaws and directly contribute to better solutions. When I got my start in web development this was just the norm because no one understood the web yet, so both traditional designers as well as human-computer interaction specialists were out of their depth, and product manager wasn't a career path that people could go into to make big bucks without any technical knowledge the way it became after the web and mobile revolutions went mainstream and tech became the new finance for the blindly ambitious.