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.
I have a similar pattern. Usually the issue ends up being not that I wrote a lot of bugs, but that I wrote the wrong thing. So as least for me it's important to drum up some users before I put too fine a finish on it.
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 agree with the mental model bit - I think this is the most important thing in a "good", "intuitive", or "learnable" product and I wish it was center stage for ux designers.
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.
It's why you get user feedback before it goes into development. Then the developers don't have to question/gamble whether things are good for the users. If you can't answer that with evidence, then you are guessing at what users might want, which can definitely be a large gamble if you are a solo developer. User opinions count as evidence in this case, and guessing is sometimes correct in certain situations though.
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.
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?"
Yeah, in my experience, basically every time too much time is spent planning rather than doing, it has a huge cost in lost time that could have been better spent proving out the foundation of the idea which would immediately inform the next steps. I've seen it so frequently. I'd rather build a quick prototype we can iterate on and prove the concept. It keeps everyone/everything grounded in a tangible reality that speaks for itself and takes the guesswork out of building.
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.
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.
Yeah, I think what they are getting at here is a bit holistic. The question(unrelated to actual code quality) happened to prompt the author to play around with the new build, which happened to result in a bug discovery. I can see how it's a good question to ask (gauges confidence in code and end product) but this is really just another feel good anecdote from middle management.
Sure, except the author is an IC, so by definition it's not from middle management.
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.
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.
I have a similar pattern. Usually the issue ends up being not that I wrote a lot of bugs, but that I wrote the wrong thing. So as least for me it's important to drum up some users before I put too fine a finish on it.
Yup.
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...
I agree with the mental model bit - I think this is the most important thing in a "good", "intuitive", or "learnable" product and I wish it was center stage for ux designers.
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.
It's why you get user feedback before it goes into development. Then the developers don't have to question/gamble whether things are good for the users. If you can't answer that with evidence, then you are guessing at what users might want, which can definitely be a large gamble if you are a solo developer. User opinions count as evidence in this case, and guessing is sometimes correct in certain situations though.
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.
Related reading (I would love to hear some feedback but I am NOT op)
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?"
Yeah, in my experience, basically every time too much time is spent planning rather than doing, it has a huge cost in lost time that could have been better spent proving out the foundation of the idea which would immediately inform the next steps. I've seen it so frequently. I'd rather build a quick prototype we can iterate on and prove the concept. It keeps everyone/everything grounded in a tangible reality that speaks for itself and takes the guesswork out of building.
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 write a lot of tutorials and explanations[0].
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/
I don't think this phrase has ever been uttered by a Facebook programmer.
Nice little post!
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
Rule #17 from where? I'd like to take a peek at what the other rules have to say!
That is quite a long list, and already tends to elicit a lot of negative karma.
Rule #6: "Perspective is earned, and cannot be given freely."
Besides, we all know truisms tend to be terrible wit... Best of luck =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.
My take from it was that the question prompted the change author to introspect his feelings about the change and revisit it, making it better.
Yeah, I think what they are getting at here is a bit holistic. The question(unrelated to actual code quality) happened to prompt the author to play around with the new build, which happened to result in a bug discovery. I can see how it's a good question to ask (gauges confidence in code and end product) but this is really just another feel good anecdote from middle management.
Sure, except the author is an IC, so by definition it's not from middle management.
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.