Become a massive value provider
Do your work so well that people get more out of it than they thought to ask for. Enough that they stop and notice. That's a standard I want to hold myself to [1].
Anyone can hand over the first thing that technically meets the request. A usable answer, a rough edit, a tool that mostly works. But there's usually another question worth asking before calling it done: what would make this seriously useful to the person receiving it?
Maybe they asked for an explanation and you give them an example that finally makes it click. Maybe they came for a video and leave with something they can actually apply. Maybe you solve a problem they expected to spend the rest of the afternoon fighting. That extra thought is where a lot of the value comes from.
Give people more than they came for
The first version of an idea is easy to settle for. You have something in front of you, it looks fine, and you want to move on. I get it. But if I never question that first attempt, I never find out how much better the work could have been.
Take a thumbnail. You can make one, decide it looks good, and upload it. Or you can try several versions and test which one gets people to open the video. With editing, you can make the cuts and export, or think about where the pacing drags and which explanation needs a visual. With a long conversation, you can leave the useful bits buried in two hours of footage, or pull them out for someone who would never watch the whole thing.
The extra work should make a difference to the person on the other end. Adding things for the sake of adding things doesn't get you there. A shorter explanation can provide more value than a longer one. A small tool can save someone more time than a huge application. You have to pay attention to what actually helps.
That's the part I find interesting: noticing a useful thing you could do before someone has to spell it out for you. Once you start looking for those opportunities, the work gives you plenty of them.
Get good enough to have something to give
There's an obvious catch. If the value is supposed to come from me, I need something worth passing on. What do I understand? What can I do well? Which problems can I solve that I couldn't solve six months ago?
You don't get an unlimited supply of useful ideas from the same shallow understanding. At some point you have to study, try things, get feedback, and fix what you're bad at. Otherwise you're dressing up the same limited knowledge and hoping nobody notices.
Research on deliberate practice makes a useful distinction here: practice aimed specifically at improving performance has structure and a target. A meta-analysis found its relationship with performance varied across fields [2]. That doesn't give me a magic number of hours to grind. It gives me a better question: what exactly am I getting better at when I do this?
If my explanations are confusing, I can work on making one difficult idea clear. If people abandon a tool during setup, I can watch where they get stuck. If an edit feels slow, I can try another cut and compare. Each attempt should teach me something I can use in the next one.
Reading matters too, but I want it connected to practice. Learn something, use it, find the gap, go back. Do that regularly and you have more to offer than you did before.
It feels better to do the job properly
There's a payoff before anyone pays you. You know whether you gave the work some actual thought or rushed out something half-assed. Getting better at something you chose to do is satisfying in its own right.
Self-determination theory treats competence and autonomy, alongside relatedness, as basic psychological needs. Its research connects conditions that support those needs with motivation and well-being [3]. My takeaway is practical: choosing a worthwhile challenge and getting capable enough to handle it can be part of what keeps the work enjoyable.
I want that from what I do. I want to look at the result and know there's something there. Praise is nice, but I don't want it to be the only reason I bother doing good work.
Make yourself worth coming back to
When someone gets a lot out of your work, you've given them a reason to remember you. They might share it, recommend you, come back for the next thing, or decide you're the person they want to pay. Being unusually useful gives people a reason to choose you again.
Reciprocity research offers some support for the underlying idea that people respond to receiving more than expected. In field experiments, unexpectedly higher pay initially led workers to put in more effort, though the difference faded after the first few hours [4]. That's a specific setting, not proof that every helpful act produces a return. Still, it shows that the extra benefit someone receives can change how they respond.
For me, the sensible move is to keep producing work people have a reason to value, make it available, and get better at doing it. If I want more independence in how I earn a living, having a skill people actively seek out is something worth building toward. I'll also need a way for them to find and pay me; being useful alone doesn't arrange that.
Become someone who can provide a ridiculous amount of value. Learn enough to have something substantial to offer, care enough to make it useful, and keep raising the standard of what you put out. I'd rather spend my time becoming that person than keep finding excuses for work I already know could be better.
Sources (4)
- Yusuf İpek ⁜ Devasa Değer Üreten Birisi Ol↩
- Macnamara, Hambrick and Oswald (2014) ⁜ Deliberate Practice and Performance: A Meta-Analysis↩
- Ryan and Deci (2000) ⁜ Self-Determination Theory and the Facilitation of Intrinsic Motivation, Social Development, and Well-Being↩
- Gneezy and List (2006) ⁜ Putting Behavioral Economics to Work: Testing for Gift Exchange in Labor Markets Using Field Experiments↩
History
Changes in v2 ⁜ 36 added, 20 removed
@@ -1,42 +1,58 @@
---
id: cryptic-watchtower-watches
-title: "Build something useful"
-summary: "Finish the part left hanging before adding another feature, stop confusing effort with results, and account for what your time is worth."
-version: 1
+title: "Become a massive value provider"
+summary: "Give people more than they came for. Build the skills to make that possible, take pride in the work, and turn useful contributions into reasons to choose you again."
+version: 2
published: 2026-10-17T17:07:41.374Z
-updated: 2026-10-17T17:07:41.374Z
+updated: 2026-10-17T20:05:44.204+00:00
language: "en"
tags: ["development"]
-sources: [{"title":"Yusuf İpek — Devasa Değer Üreten Birisi Ol (Become Someone Who Provides Massive Value)","url":"https://yusufipek.me/yazilar/devasa-deger"},{"title":"Macnamara, Hambrick and Oswald (2014) — Deliberate Practice and Performance: A Meta-Analysis","url":"https://pubmed.ncbi.nlm.nih.gov/24986855/"}]
+sources: [{"title":"Yusuf İpek — Devasa Değer Üreten Birisi Ol","url":"https://yusufipek.me/yazilar/devasa-deger"},{"title":"Macnamara, Hambrick and Oswald (2014) — Deliberate Practice and Performance: A Meta-Analysis","url":"https://pubmed.ncbi.nlm.nih.gov/24986855/"},{"title":"Ryan and Deci (2000) — Self-Determination Theory and the Facilitation of Intrinsic Motivation, Social Development, and Well-Being","url":"https://selfdeterminationtheory.org/SDT/documents/2000_RyanDeci_SDT.pdf"},{"title":"Gneezy and List (2006) — Putting Behavioral Economics to Work: Testing for Gift Exchange in Labor Markets Using Field Experiments","url":"https://doi.org/10.1111/j.1468-0262.2006.00707.x"}]
---
-When I look at a project, the first thing I want to know is how it holds up when I actually use it. Can I get it running? Does the setup break somewhere stupid? When something blows up, can I figure out what happened? Without those answers, a long feature list in the README doesn't mean much.
+**Do your work so well that people get more out of it than they thought to ask for.** Enough that they stop and notice. That's a standard I want to hold myself to [1].
-Yusuf İpek writes about going a little beyond what people expect from your work [1]. Thinking it through. Getting better at it. When I apply that idea to software, finishing the part left hanging comes to mind before adding another feature.
+Anyone can hand over the first thing that technically meets the request. A usable answer, a rough edit, a tool that mostly works. But there's usually another question worth asking before calling it done: what would make this seriously useful to the person receiving it?
-## When you say it works
+Maybe they asked for an explanation and you give them an example that finally makes it click. Maybe they came for a video and leave with something they can actually apply. Maybe you solve a problem they expected to spend the rest of the afternoon fighting. That extra thought is where a lot of the value comes from.
-Say you write a tool. It runs on your machine, but someone else installs it and it crashes because a setting is missing. Then you have to explain which setting they need. The code might technically work. But part of the solution is still sitting in your head.
+## Give people more than they came for
-An error message that names the missing setting, a setup guide you've actually tried, or a sensible default can be more useful than another feature. The user might never have asked for any of that. They shouldn't have to predict where they'll get stuck. I built the thing; I can do some of the thinking here too.
+The first version of an idea is easy to settle for. You have something in front of you, it looks fine, and you want to move on. I get it. But if I never question that first attempt, I never find out how much better the work could have been.
-That's what I take providing extra value to mean: accounting for the part of the job that happens on the other person's end. A script that removes a repetitive manual task can do more for someone than ten settings screens. An explanation that saves them from asking the same question again does something useful too.
+Take a thumbnail. You can make one, decide it looks good, and upload it. Or you can try several versions and test which one gets people to open the video. With editing, you can make the cuts and export, or think about where the pacing drags and which explanation needs a visual. With a long conversation, you can leave the useful bits buried in two hours of footage, or pull them out for someone who would never watch the whole thing.
-## Putting in hours is easy
+**The extra work should make a difference to the person on the other end.** Adding things for the sake of adding things doesn't get you there. A shorter explanation can provide more value than a longer one. A small tool can save someone more time than a huge application. You have to pay attention to what actually helps.
-Sinking hours into something doesn't make it good. You can keep repeating the same mistake and call that practice.
+That's the part I find interesting: noticing a useful thing you could do before someone has to spell it out for you. Once you start looking for those opportunities, the work gives you plenty of them.
-A meta-analysis of deliberate practice and performance found that the relationship varies across fields [2]. I wouldn't read that as a promise that whoever puts in more work wins. The amount of effort alone doesn't explain the outcome.
+## Get good enough to have something to give
-If I spend all my time reading a tool's documentation, I still don't know whether I can do anything with it. I'd rather build something small, see where I get stuck, look into that part, and try again. That gives what I'm reading some context. I don't want learning to become an endless preparation phase either.
+There's an obvious catch. If the value is supposed to come from me, **I need something worth passing on.** What do I understand? What can I do well? Which problems can I solve that I couldn't solve six months ago?
-The same goes for feedback. If someone gets stuck during setup, saying “works on my machine” gets us nowhere. I need to see where they got stuck. Sometimes the thing that needs fixing isn't even code. It's a bad assumption or two unclear sentences.
+You don't get an unlimited supply of useful ideas from the same shallow understanding. At some point you have to study, try things, get feedback, and fix what you're bad at. Otherwise you're dressing up the same limited knowledge and hoping nobody notices.
-## Who's going to pay you back?
+Research on deliberate practice makes a useful distinction here: practice aimed specifically at improving performance has structure and a target. A meta-analysis found its relationship with performance varied across fields [2]. That doesn't give me a magic number of hours to grind. It gives me a better question: **what exactly am I getting better at when I do this?**
-I'm less comfortable with the source article's suggestion that the value you provide will eventually come back to you [1]. Good work can go unnoticed. You can build something very well that nobody needs. Someone can benefit from what you made and give you nothing in return. There's no automatic fairness mechanism running in the background.
+If my explanations are confusing, I can work on making one difficult idea clear. If people abandon a tool during setup, I can watch where they get stuck. If an edit feels slow, I can try another cut and compare. Each attempt should teach me something I can use in the next one.
-So I want to know why I'm doing the work. Am I solving my own problem, learning something, or trying to make money? Each calls for a different calculation. If I keep expanding the scope just to get noticed, I can end up never finishing the thing. My time has to count too.
+Reading matters too, but I want it connected to practice. Learn something, use it, find the gap, go back. Do that regularly and you have more to offer than you did before.
-Still, I don't like doing a half-assed job. If I choose to build something, I want to take it far enough that someone else can actually use it. I don't need to add every idea or solve every possible case. It can be small. It should do its job properly and be clear about its limits.
+## It feels better to do the job properly
+There's a payoff before anyone pays you. You know whether you gave the work some actual thought or rushed out something half-assed. Getting better at something you chose to do is satisfying in its own right.
+
+Self-determination theory treats competence and autonomy, alongside relatedness, as basic psychological needs. Its research connects conditions that support those needs with motivation and well-being [3]. My takeaway is practical: choosing a worthwhile challenge and getting capable enough to handle it can be part of what keeps the work enjoyable.
+
+I want that from what I do. I want to look at the result and know there's something there. Praise is nice, but I don't want it to be the only reason I bother doing good work.
+
+## Make yourself worth coming back to
+
+When someone gets a lot out of your work, you've given them a reason to remember you. They might share it, recommend you, come back for the next thing, or decide you're the person they want to pay. **Being unusually useful gives people a reason to choose you again.**
+
+Reciprocity research offers some support for the underlying idea that people respond to receiving more than expected. In field experiments, unexpectedly higher pay initially led workers to put in more effort, though the difference faded after the first few hours [4]. That's a specific setting, not proof that every helpful act produces a return. Still, it shows that the extra benefit someone receives can change how they respond.
+
+For me, the sensible move is to keep producing work people have a reason to value, make it available, and get better at doing it. If I want more independence in how I earn a living, having a skill people actively seek out is something worth building toward. I'll also need a way for them to find and pay me; being useful alone doesn't arrange that.
+
+**Become someone who can provide a ridiculous amount of value.** Learn enough to have something substantial to offer, care enough to make it useful, and keep raising the standard of what you put out. I'd rather spend my time becoming that person than keep finding excuses for work I already know could be better.
+
v1 ⁜
When I look at a project, the first thing I want to know is how it holds up when I actually use it. Can I get it running? Does the setup break somewhere stupid? When something blows up, can I figure out what happened? Without those answers, a long feature list in the README doesn't mean much.
Yusuf İpek writes about going a little beyond what people expect from your work [1]. Thinking it through. Getting better at it. When I apply that idea to software, finishing the part left hanging comes to mind before adding another feature.
When you say it works
Say you write a tool. It runs on your machine, but someone else installs it and it crashes because a setting is missing. Then you have to explain which setting they need. The code might technically work. But part of the solution is still sitting in your head.
An error message that names the missing setting, a setup guide you've actually tried, or a sensible default can be more useful than another feature. The user might never have asked for any of that. They shouldn't have to predict where they'll get stuck. I built the thing; I can do some of the thinking here too.
That's what I take providing extra value to mean: accounting for the part of the job that happens on the other person's end. A script that removes a repetitive manual task can do more for someone than ten settings screens. An explanation that saves them from asking the same question again does something useful too.
Putting in hours is easy
Sinking hours into something doesn't make it good. You can keep repeating the same mistake and call that practice.
A meta-analysis of deliberate practice and performance found that the relationship varies across fields [2]. I wouldn't read that as a promise that whoever puts in more work wins. The amount of effort alone doesn't explain the outcome.
If I spend all my time reading a tool's documentation, I still don't know whether I can do anything with it. I'd rather build something small, see where I get stuck, look into that part, and try again. That gives what I'm reading some context. I don't want learning to become an endless preparation phase either.
The same goes for feedback. If someone gets stuck during setup, saying “works on my machine” gets us nowhere. I need to see where they got stuck. Sometimes the thing that needs fixing isn't even code. It's a bad assumption or two unclear sentences.
Who's going to pay you back?
I'm less comfortable with the source article's suggestion that the value you provide will eventually come back to you [1]. Good work can go unnoticed. You can build something very well that nobody needs. Someone can benefit from what you made and give you nothing in return. There's no automatic fairness mechanism running in the background.
So I want to know why I'm doing the work. Am I solving my own problem, learning something, or trying to make money? Each calls for a different calculation. If I keep expanding the scope just to get noticed, I can end up never finishing the thing. My time has to count too.
Still, I don't like doing a half-assed job. If I choose to build something, I want to take it far enough that someone else can actually use it. I don't need to add every idea or solve every possible case. It can be small. It should do its job properly and be clear about its limits.