3 ms·

> Read the Reference > Don’t Guess I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive

> Read the Reference > Don’t Guess I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive into the reference. Or, I'll read a stackoverflow answer or two, play around with it, and then go to reference. Why? Often there's a lot of context in the reference that only makes sense once I've had some hands-on time with whatever the reference is describing. This is especially the case when learning a new language or API: I'll go through a tutorial / quickstart; "guess" at making a change; and then go back and read the reference with a better understanding of the context. BTW: This is why I like languages and IDEs that support things like intellisense. It's great to be able to see little bits of documentation show up in my IDE to help me in my "guess" stage of learning.

metalliqaz 2y ago
same. It is so hard to write good documentation, especially when the author is also the designer. There is so much context that is easy to take for granted and thus leave out.
palmotea 2y ago
>> Read the Reference >> Don’t Guess > I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive into the reference. Or, I'll read a stackoverflow answer or two, play around with it, and then go to reference. I think that's fair. I've definitely seen "not best" programmers only guess and only read stackoverflow, over and over, forever, and never read the reference. They have no idea what's going on and just spin making a mess in until something sticks. I kinda read that item as a response to people like that.
- 9rx 2y ago
  The trouble is that there is a strong correlation between being able to design good interfaces and being able to prepare good documentation. Meaning, where guessing fails, the reference is bound to also fail due to inaccuracies or failing to communicate what you need to know. Which stands to reason as both require concern for how the user perceives the product. That is a skill in its own right. In practice, so many times I've spun my wheels thinking I just didn't understand the reference only to find out that there was a bug or change that invalidated the reference. Nowadays, if I must interface with a product built buy someone who doesn't understand the user, I'll go straight to the source code if guessing fails or resort to probing the system if code isn't available. Not only is it faster, but you'll gain a better understanding of what is going on than some stumbling attempt to describe it in natural language will ever be able to communicate.
  - palmotea 2y ago
    > The trouble is that there is a strong correlation between being able to design good interfaces and being able to prepare good documentation. Meaning, where guessing fails, the reference is bound to also fail due to inaccuracies or failing to communicate what you need to know. Which stands to reason as both require concern for how the user perceives the product. I think we're talking about different kinds of guessing. I'm not talking about skilled educated guessing, I'm talking about dumb, ignorant guessing. Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. Those people do that even with the most beautiful interfaces with the best documentation. But even with the best designed interfaces, not everything is discoverable (e.g. another fantastically designed but orthogonal interface in the same library that solves your problem).
    - 9rx 2y ago
      > Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. A reasonable place to start. But fair that you can't stop there if it isn't working. Next step, in my opinion, is to look at the interface more closely to see if it provides any hints. It will most of the time if it is well designed. > But even with the best designed interfaces, not everything is discoverable Sure. That's what the test suite is for, though: To document for users full intent and usage. You're still not going to go to a reference for that. As an added bonus, it is self-validating, so none of the "is it me or is the reference incorrect?" rigamarole.
      - palmotea 2y ago
        >> Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. > A reasonable place to start. But fair that you can't stop there if it isn't working. It's not a reasonable place to start. You're basically talking about copy-paste coding. Google search, stack overflow, paste in the first answer. Afterwards, ask the dev if they know what they did and why it works, and they won't be able to answer because they don't know. > Next step, in my opinion, is to look at the interface more closely to see if it provides any hints. It will most of the time if it is well designed. The people I'm taking about can't and won't do that. > Sure. That's what the test suite is for, though: To document for users full intent and usage. You're still not going to go to a reference for that. As an added bonus, it is self-validating, so none of the "is it me or is the reference incorrect?" rigamarole. I'm getting an "I don't need comments because code is self-documenting" vibe here. I disagree with that. Prose is a better way to express many, many things related to code than the code itself or even its test. Sure, the code is the most authoritative place to find what was implemented, but it's not the best way to find the why or the concepts and thought behind it.
ctxc 2y ago
This is why I tend to Google instead of chatgpt everything. I always end up finding these little interesting nuggets in comments/threads in SO
- socksy 2y ago
  I think my preferred LLM usage style these days is to try something on my own, and then get the LLM to critique what I did. I think it's both better for learning (just like learning natural languages, it's better for learning to make a mistake and be corrected than it is to look up the right answer each time), and also I think the stakes are lower since you're not relying on the LLM to not hallucinate. You can also learn some new threads to pull on that you can investigate on your own etc
  - ctxc 2y ago
    Makes sense. I learnt swift recently with LLM as my first starting point - basically "I know java and python, explain swift syntax". It was great. Once I got to architecture I got a general direction and relied on googling (eg. Lots of nuance to if I should use swiftData/coreData/sqlite etc found in conversation threads)
  - skydhash 2y ago
    If I’m writing in an unfamiliar language or using an unfamiliar library, I will mostly have several browser tabs opened. That’s because the docs usually have caveats and other tips that will be missing from LLMs. And a book can do wonders for strengthening your foundations.
perrygeo 2y ago
Agreed. Make a guess, then verify that guess with running code, repeat. I'm surprised this is controversial; engineering ostensibly follows the scientific method. Without forming hypotheses and testing them, there is no scientific method. Unless we want to nitpick the difference between guessing and hypothesizing, making guesses is a critical part of programming. I always come back to Peter Naur’s essay "Programming as Theory Building". It's 40 years old now but still nails the essence of programming. The value produced by programming is a shared working theory of the system, not the source code itself. I can't see how you would develop a sufficient theory without first forming hypotheses.
- d0mine 2y ago
  Formulating your assumptions before you run code and check saves you from rationalizing after the fact whatever behavior you happen to observe. Invalid predictions help improve understanding, learn.
Winsaucerer 2y ago
Interesting, I had a similar approach while studying philosophy. I much prefer to think and write than read, so I'd often think through a philosophical problem first, and then read others on the topic. I'd find that this order helped me grasp a topic well. I don't know if I do the same thing with programming.
iamwpj 2y ago
I agree with this. I have to learn a lot about a new tool before I can effectively use the docs (beyond the getting started). If it's area where I'm already familiar, then sometimes I can jump in pretty easily, but often fumbling is a key step.
mycall 2y ago
Middle-out learning is a great way to tackle brand new things. Do some overviews, see what other people do and think about the thing, then dive into it's manual once you have a worldview of it.
d0mine 2y ago
Actually, your approach “test yourself first, then learn” is better for learning compared with just learning first according to research.
alphazard 2y ago
I think people are going to interpret "Don't Guess" in a way that is totally impractical and not what the best programmers do. You should have a strong sense of the model that a tool or library presents to you as the consumer. And you should use that model to "guess" about the behavior of the tool. You should choose tools that are coherent, so that your guesses are more accurate than not, and avoid using libraries/tools with many special cases that make it hard to "guess" what they do. The best programmers do not double check the docs or implementation for every function that they call. They are good at writing tests that check lots of their assumptions at once, and they are good at choosing tools that let them guess reliably, and avoiding tools that cause them to guess incorrectly. Leverage in programming comes from the things you don't have to understand and the code you don't have to read in order to accomplish a goal.
wging 2y ago
I don't think your approach is bad, nor is it in conflict with the advice in the article, at least in spirit. You aren't (I think) describing a situation where your untested guesses end up in a released product, or in ill-founded advice to colleagues. (Both of those actually do happen.) Forming and testing hypotheses is valuable, building on unfounded assumptions is a very different thing.
asdfman123 2y ago
I also find it damn near impossible to focus on the reference. I know it sounds childish, but I just can't do it sometimes. Playing around with code is how I got here.
- gwbas1c 2y ago
  Honestly, some references are very confusing. Sometimes they "say everything," but don't give enough context to really understand. That's why examples are also critical.

metalliqaz 2y ago

same. It is so hard to write good documentation, especially when the author is also the designer. There is so much context that is easy to take for granted and thus leave out.

palmotea 2y ago

>> Read the Reference >> Don’t Guess > I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive into the reference. Or, I'll read a stackoverflow answer or two, play around with it, and then go to reference. I think that's fair. I've definitely seen "not best" programmers only guess and only read stackoverflow, over and over, forever, and never read the reference. They have no idea what's going on and just spin making a mess in until something sticks. I kinda read that item as a response to people like that.

9rx 2y ago
The trouble is that there is a strong correlation between being able to design good interfaces and being able to prepare good documentation. Meaning, where guessing fails, the reference is bound to also fail due to inaccuracies or failing to communicate what you need to know. Which stands to reason as both require concern for how the user perceives the product. That is a skill in its own right. In practice, so many times I've spun my wheels thinking I just didn't understand the reference only to find out that there was a bug or change that invalidated the reference. Nowadays, if I must interface with a product built buy someone who doesn't understand the user, I'll go straight to the source code if guessing fails or resort to probing the system if code isn't available. Not only is it faster, but you'll gain a better understanding of what is going on than some stumbling attempt to describe it in natural language will ever be able to communicate.
- palmotea 2y ago
  > The trouble is that there is a strong correlation between being able to design good interfaces and being able to prepare good documentation. Meaning, where guessing fails, the reference is bound to also fail due to inaccuracies or failing to communicate what you need to know. Which stands to reason as both require concern for how the user perceives the product. I think we're talking about different kinds of guessing. I'm not talking about skilled educated guessing, I'm talking about dumb, ignorant guessing. Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. Those people do that even with the most beautiful interfaces with the best documentation. But even with the best designed interfaces, not everything is discoverable (e.g. another fantastically designed but orthogonal interface in the same library that solves your problem).
  - 9rx 2y ago
    > Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. A reasonable place to start. But fair that you can't stop there if it isn't working. Next step, in my opinion, is to look at the interface more closely to see if it provides any hints. It will most of the time if it is well designed. > But even with the best designed interfaces, not everything is discoverable Sure. That's what the test suite is for, though: To document for users full intent and usage. You're still not going to go to a reference for that. As an added bonus, it is self-validating, so none of the "is it me or is the reference incorrect?" rigamarole.
    - palmotea 2y ago
      >> Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. > A reasonable place to start. But fair that you can't stop there if it isn't working. It's not a reasonable place to start. You're basically talking about copy-paste coding. Google search, stack overflow, paste in the first answer. Afterwards, ask the dev if they know what they did and why it works, and they won't be able to answer because they don't know. > Next step, in my opinion, is to look at the interface more closely to see if it provides any hints. It will most of the time if it is well designed. The people I'm taking about can't and won't do that. > Sure. That's what the test suite is for, though: To document for users full intent and usage. You're still not going to go to a reference for that. As an added bonus, it is self-validating, so none of the "is it me or is the reference incorrect?" rigamarole. I'm getting an "I don't need comments because code is self-documenting" vibe here. I disagree with that. Prose is a better way to express many, many things related to code than the code itself or even its test. Sure, the code is the most authoritative place to find what was implemented, but it's not the best way to find the why or the concepts and thought behind it.

ctxc 2y ago

This is why I tend to Google instead of chatgpt everything. I always end up finding these little interesting nuggets in comments/threads in SO

socksy 2y ago
I think my preferred LLM usage style these days is to try something on my own, and then get the LLM to critique what I did. I think it's both better for learning (just like learning natural languages, it's better for learning to make a mistake and be corrected than it is to look up the right answer each time), and also I think the stakes are lower since you're not relying on the LLM to not hallucinate. You can also learn some new threads to pull on that you can investigate on your own etc
- ctxc 2y ago
  Makes sense. I learnt swift recently with LLM as my first starting point - basically "I know java and python, explain swift syntax". It was great. Once I got to architecture I got a general direction and relied on googling (eg. Lots of nuance to if I should use swiftData/coreData/sqlite etc found in conversation threads)
- skydhash 2y ago
  If I’m writing in an unfamiliar language or using an unfamiliar library, I will mostly have several browser tabs opened. That’s because the docs usually have caveats and other tips that will be missing from LLMs. And a book can do wonders for strengthening your foundations.

perrygeo 2y ago

Agreed. Make a guess, then verify that guess with running code, repeat. I'm surprised this is controversial; engineering ostensibly follows the scientific method. Without forming hypotheses and testing them, there is no scientific method. Unless we want to nitpick the difference between guessing and hypothesizing, making guesses is a critical part of programming. I always come back to Peter Naur’s essay "Programming as Theory Building". It's 40 years old now but still nails the essence of programming. The value produced by programming is a shared working theory of the system, not the source code itself. I can't see how you would develop a sufficient theory without first forming hypotheses.

d0mine 2y ago
Formulating your assumptions before you run code and check saves you from rationalizing after the fact whatever behavior you happen to observe. Invalid predictions help improve understanding, learn.

Winsaucerer 2y ago

Interesting, I had a similar approach while studying philosophy. I much prefer to think and write than read, so I'd often think through a philosophical problem first, and then read others on the topic. I'd find that this order helped me grasp a topic well. I don't know if I do the same thing with programming.

iamwpj 2y ago

I agree with this. I have to learn a lot about a new tool before I can effectively use the docs (beyond the getting started). If it's area where I'm already familiar, then sometimes I can jump in pretty easily, but often fumbling is a key step.

mycall 2y ago

Middle-out learning is a great way to tackle brand new things. Do some overviews, see what other people do and think about the thing, then dive into it's manual once you have a worldview of it.

d0mine 2y ago

Actually, your approach “test yourself first, then learn” is better for learning compared with just learning first according to research.

alphazard 2y ago

I think people are going to interpret "Don't Guess" in a way that is totally impractical and not what the best programmers do. You should have a strong sense of the model that a tool or library presents to you as the consumer. And you should use that model to "guess" about the behavior of the tool. You should choose tools that are coherent, so that your guesses are more accurate than not, and avoid using libraries/tools with many special cases that make it hard to "guess" what they do. The best programmers do not double check the docs or implementation for every function that they call. They are good at writing tests that check lots of their assumptions at once, and they are good at choosing tools that let them guess reliably, and avoiding tools that cause them to guess incorrectly. Leverage in programming comes from the things you don't have to understand and the code you don't have to read in order to accomplish a goal.

wging 2y ago

I don't think your approach is bad, nor is it in conflict with the advice in the article, at least in spirit. You aren't (I think) describing a situation where your untested guesses end up in a released product, or in ill-founded advice to colleagues. (Both of those actually do happen.) Forming and testing hypotheses is valuable, building on unfounded assumptions is a very different thing.

asdfman123 2y ago

I also find it damn near impossible to focus on the reference. I know it sounds childish, but I just can't do it sometimes. Playing around with code is how I got here.

gwbas1c 2y ago
Honestly, some references are very confusing. Sometimes they "say everything," but don't give enough context to really understand. That's why examples are also critical.