3 ms·

By actually Googling things?! Your specific experience might be different from mine as well. In most places I have been there were lots of 'standard' things in

By actually Googling things?! Your specific experience might be different from mine as well. In most places I have been there were lots of 'standard' things in use that were easily Google-able. You may also mainly work in languages that make it hard to find things you don't already have a mental model of (scripting languages, untyped languages etc.) vs. where I like working: typed languages where I can let the IDE guide me through. Frameworks that make things easily string searchable etc. There's a price for not asking: To take the example I gave before. If you take 2 weeks to get up to "I can deploy code for development and debug it" that's a bad sign. If you're up an running in a day or two, you're usually golden.

watwut 4y ago
So in the end, the actual advice is not to ask questions and hope for doing it by yourself. Also, people coming from dynamic languages won't ask a out IDE, because they are from environment where IDE helps much less and also where it is looked down at. The stuff you claim one should ask about, is stuff that you team should explain to you in the first place. There is literally no reasonable question, just some workaround for "my team does not have Readme, won't tell me they have secret steps for running project and absurdly will blame me if I won't make it fast".
- tharkun__ 4y ago
  You said you don't trust your new social group yet. You've been burned too many times. You asked: How does the new person distinguish between googlable question and company specific The answer to that is to try and Google it. If you get a result, it's probably Google-able and you can go further from that if you "don't trust the new social group yet". If you trust the group, ask them. You're the one that said they needed to be super cautious, so don't put that on me. Do tell me, what stuff did I say one should ask about, that the team should explain in the first place? Why would these questions not be reasonable? What I can tell you is that we have a `README.md` in every service. We have our onboarding docs directly in the source as well as markdown files. Every new developer's first PR is to improve the onboarding documentation. Regardless of that, most developers do find something to actually improve, even if it's just adding a cross-referencing link between docs or moving stuff around, so that it's documented in the right place in the onboarding flow. Of course, if your documentation is perfect for every situation and every type of person I commend you. In my experience, there's always one thing or another that someone doesn't understand or where a step is missing. Not because it's secret, but for example because everyone (so far) thought it was obvious. Take the example of a command you're supposed to run but replace one or more of the parameters with your own values. So let's actually make an example of something where people should ask because it's not Googlable. Take an imaginary part of some setup documentation like for example Replace the parameter with your own baseUrl you chose in step 1 and run `someScript.sh https://example.com/yourBaseUrl` to create the basic setup. And they literally copy and paste this without changing the parameter, even if the documentation tells them where to get this parameter from and to replace it before running. This is not "Google-able" if this is an internal script and while it's definitely on some level "not so smart", we've all misread something, skipped a sentence or overlooked a parameter that wasn't properly marked and I'd rather they just ask than take 3 hours doctoring around and not getting a single step further. One improvement the next dev might make is to change it to Replace the parameter with your own baseUrl you chose in step 1 and run `someScript.sh <yourBaseUrl>` to create the basic setup. You know what's gonna happen? Someone will come along and copy and paste this straight without thinking and take 3 hours to get anywhere.

watwut 4y ago

So in the end, the actual advice is not to ask questions and hope for doing it by yourself. Also, people coming from dynamic languages won't ask a out IDE, because they are from environment where IDE helps much less and also where it is looked down at. The stuff you claim one should ask about, is stuff that you team should explain to you in the first place. There is literally no reasonable question, just some workaround for "my team does not have Readme, won't tell me they have secret steps for running project and absurdly will blame me if I won't make it fast".

tharkun__ 4y ago
You said you don't trust your new social group yet. You've been burned too many times. You asked: How does the new person distinguish between googlable question and company specific The answer to that is to try and Google it. If you get a result, it's probably Google-able and you can go further from that if you "don't trust the new social group yet". If you trust the group, ask them. You're the one that said they needed to be super cautious, so don't put that on me. Do tell me, what stuff did I say one should ask about, that the team should explain in the first place? Why would these questions not be reasonable? What I can tell you is that we have a `README.md` in every service. We have our onboarding docs directly in the source as well as markdown files. Every new developer's first PR is to improve the onboarding documentation. Regardless of that, most developers do find something to actually improve, even if it's just adding a cross-referencing link between docs or moving stuff around, so that it's documented in the right place in the onboarding flow. Of course, if your documentation is perfect for every situation and every type of person I commend you. In my experience, there's always one thing or another that someone doesn't understand or where a step is missing. Not because it's secret, but for example because everyone (so far) thought it was obvious. Take the example of a command you're supposed to run but replace one or more of the parameters with your own values. So let's actually make an example of something where people should ask because it's not Googlable. Take an imaginary part of some setup documentation like for example Replace the parameter with your own baseUrl you chose in step 1 and run `someScript.sh https://example.com/yourBaseUrl` to create the basic setup. And they literally copy and paste this without changing the parameter, even if the documentation tells them where to get this parameter from and to replace it before running. This is not "Google-able" if this is an internal script and while it's definitely on some level "not so smart", we've all misread something, skipped a sentence or overlooked a parameter that wasn't properly marked and I'd rather they just ask than take 3 hours doctoring around and not getting a single step further. One improvement the next dev might make is to change it to Replace the parameter with your own baseUrl you chose in step 1 and run `someScript.sh <yourBaseUrl>` to create the basic setup. You know what's gonna happen? Someone will come along and copy and paste this straight without thinking and take 3 hours to get anywhere.