6 ms·

I very rarely use stackoverflow as well. Last time was probably week ago when googling something bash related. AMA

startupdiscuss 9y ago
Well, let me ask you the same questions: 1. What is your development environment? 2. What you do when there is an issue?
- cstrahan 9y ago
  I'm not the parent, but here's what I'd do (and, indeed, have done): Read the manual: https://www.gnu.org/software/bash/manual/bash.html https://www.gnu.org/software/bash/manual/bash.html Just sit down one weekend, and read it from beginning to end. The information contained therein is just about exhaustive. Assuming you touch bash scripts daily (as I do), there's really little excuse for not mastering the language. Referring to SO every time you stumble into an issue is inefficient compared to the one time cost of actually developing working knowledge of the subject at hand, and it also limits you to the canned solutions that a bunch of random people on the internet have proposed. I'd bet my money on you being more capable than a random stranger -- assuming you've read up first. When I was at an earlier stage in my career, I'd hit up SO every time I ran into an issue. And then I had the realization that I could just read up on: * The spec for your language(s) * The source code for the compiler and/or VMs that power your language(s) * The manual for the software you use * The RFCs that apply to you * Both the public API and the internal source code of the libraries you use * Etc
  - falcolas 9y ago
    Amen. Writing a bash script? Branch off a separate terminal and type `man bash`.
    - scalatohaskell 9y ago
      I have a big distaste for bash, and am happy to copy paste anything similar from stackoverflow. Shame on me though!
      - falcolas 9y ago
        My biggest concern with this is that there are a lot of really terrible bash script writers out there on the internet, and the quality of code between two different answers will vary wildly. I'm not going to claim to be a great bash script writer, but I'm better than 80% of what I see out there. Throwing together random fragments is going to cause nearly as many problems as it's meant to solve.
        scalatohaskell 9y ago
        This is very true, and it has happened to me. Luckily I dont write anything critical in bash, there are usually better suited people for that. I am just a big crybaby without compiler :(
        i336_ 9y ago
        Out of curiosity, what do you currently dislike about the shell, if anything? I'm not setting up a "you hate the shell" statement here - hashing out gripes and dislikes can sometimes be a great way to jump straight into the middle of an iterative positive feedback loop of learning. (Or at least I think so, anyway. I think that if I did that myself it would identify the (sometimes not intuitive) blocks and glitches I have with things more quickly than I figure them out in the end.) Oh, also - note that there is a lot I outright hate about the shell myself, but which is due to its, shall way say, overly organic development over the last ~20 years.
        scalatohaskell 9y ago
        I think it's mostly that I need to write it so little, that I never get to become proficient "enough" with it. There is little motivation to invest hours to learn it properly, because a) I get to write bash scripts so little that b) I would forgot half by next time I use it. I think I'm basically stuck on the worst part of learning curve. Btw I use console for pretty much everything from git shell to vim. But when I have to run-in-parallel/fork two processes, pipe X from some to third one that has to repeatedly do curls to some service and check http response, there are 10 things I need to google, starting from: -how to fork process, how to pipe process, how to IF in bash, how do LOOP in bash, etc. Worst thing is, I've googled this 10 times before, but never remember the syntax etc.
  - emmelaich 9y ago
    I did something similar at the start of my admin/programming career. 1. Read the entire UNIX manual (wasn't that big at the time) 2. Read Rochkind "Advanced UNIX Programming" 3. Read K&R "The C Programming Language" 4. Read K&P "The UNIX Programming Environment" sometime later I also read (parts of) Stevens UNIX Networking. I'd say these made a very strong base from which to learning everything else.
- scalatohaskell 9y ago
  Ubuntu. IntelliJ +Scala plugin. I write Scala 90% of the time. 99% of the time, before I call any function, I jump "navigate to source" in intelliJ, and have a quick glance on it. Most of the time, type ascription is enough, sometimes I skim through doc, and occasionally, if it's sketchy library, I look at implementation. This is very quick process that takes maybe 10-15seconds. Sometimes when Im not under pressure, while I'm at sources, I check also some similiar APIs, and implementation, to see and learn 'hows' and 'whys'. Using this I quickly gain pretty solid knowledge of libraries I use. If I'm really stuck, I opened 3d party github, and scan issues, to see if there's something similiar. Lots of times there is issue or something, but I'll admit, lots of time there isn't. This is when I start googling, which sometimes take me to Stackoverflow. If not, I use gitter to ask authors. But this happen very rarely. Mostly all I need to do is dictated by library types I use. Occasionally, with shitty libraries that bring external configuration I have to check their docs on github. But I think it may be language related. Or experience perhaps. I had to do a bit of javascript with node.js (2 weeks +-), and I visited SO very very very often. Normally whenever I'm learning new language or framework, navigating to sources is my fasttrack to both language and framework/lib. There isn't a better way to learn what's right way to do stuff than to see authors of battle tested libraries solving difficult problems, and learning from their style. I can recommend that :) I'll admit your mileage may vary, and this may be specific to my job, but I'm pretty happy with this workflow, and I don't have anything against people using SO or something. Edit: I had forgotten important part - occasionally I spin REPL and try what library really does there. But that's also one of last resorts, when I'm stuck :) In Scala we have http://www.lihaoyi.com/Ammonite/ http://www.lihaoyi.com/Ammonite/ which makes it super easy to fetch and use external dependencies etc... so I guess tooling is also important part.

Well, let me ask you the same questions: 1. What is your development environment? 2. What you do when there is an issue?

cstrahan 9y ago
I'm not the parent, but here's what I'd do (and, indeed, have done): Read the manual: https://www.gnu.org/software/bash/manual/bash.html https://www.gnu.org/software/bash/manual/bash.html Just sit down one weekend, and read it from beginning to end. The information contained therein is just about exhaustive. Assuming you touch bash scripts daily (as I do), there's really little excuse for not mastering the language. Referring to SO every time you stumble into an issue is inefficient compared to the one time cost of actually developing working knowledge of the subject at hand, and it also limits you to the canned solutions that a bunch of random people on the internet have proposed. I'd bet my money on you being more capable than a random stranger -- assuming you've read up first. When I was at an earlier stage in my career, I'd hit up SO every time I ran into an issue. And then I had the realization that I could just read up on: * The spec for your language(s) * The source code for the compiler and/or VMs that power your language(s) * The manual for the software you use * The RFCs that apply to you * Both the public API and the internal source code of the libraries you use * Etc
- falcolas 9y ago
  Amen. Writing a bash script? Branch off a separate terminal and type `man bash`.
  - scalatohaskell 9y ago
    I have a big distaste for bash, and am happy to copy paste anything similar from stackoverflow. Shame on me though!
    - falcolas 9y ago
      My biggest concern with this is that there are a lot of really terrible bash script writers out there on the internet, and the quality of code between two different answers will vary wildly. I'm not going to claim to be a great bash script writer, but I'm better than 80% of what I see out there. Throwing together random fragments is going to cause nearly as many problems as it's meant to solve.
      - scalatohaskell 9y ago
        This is very true, and it has happened to me. Luckily I dont write anything critical in bash, there are usually better suited people for that. I am just a big crybaby without compiler :(
        i336_ 9y ago
        Out of curiosity, what do you currently dislike about the shell, if anything? I'm not setting up a "you hate the shell" statement here - hashing out gripes and dislikes can sometimes be a great way to jump straight into the middle of an iterative positive feedback loop of learning. (Or at least I think so, anyway. I think that if I did that myself it would identify the (sometimes not intuitive) blocks and glitches I have with things more quickly than I figure them out in the end.) Oh, also - note that there is a lot I outright hate about the shell myself, but which is due to its, shall way say, overly organic development over the last ~20 years.
        scalatohaskell 9y ago
        I think it's mostly that I need to write it so little, that I never get to become proficient "enough" with it. There is little motivation to invest hours to learn it properly, because a) I get to write bash scripts so little that b) I would forgot half by next time I use it. I think I'm basically stuck on the worst part of learning curve. Btw I use console for pretty much everything from git shell to vim. But when I have to run-in-parallel/fork two processes, pipe X from some to third one that has to repeatedly do curls to some service and check http response, there are 10 things I need to google, starting from: -how to fork process, how to pipe process, how to IF in bash, how do LOOP in bash, etc. Worst thing is, I've googled this 10 times before, but never remember the syntax etc.
- emmelaich 9y ago
  I did something similar at the start of my admin/programming career. 1. Read the entire UNIX manual (wasn't that big at the time) 2. Read Rochkind "Advanced UNIX Programming" 3. Read K&R "The C Programming Language" 4. Read K&P "The UNIX Programming Environment" sometime later I also read (parts of) Stevens UNIX Networking. I'd say these made a very strong base from which to learning everything else.
scalatohaskell 9y ago
Ubuntu. IntelliJ +Scala plugin. I write Scala 90% of the time. 99% of the time, before I call any function, I jump "navigate to source" in intelliJ, and have a quick glance on it. Most of the time, type ascription is enough, sometimes I skim through doc, and occasionally, if it's sketchy library, I look at implementation. This is very quick process that takes maybe 10-15seconds. Sometimes when Im not under pressure, while I'm at sources, I check also some similiar APIs, and implementation, to see and learn 'hows' and 'whys'. Using this I quickly gain pretty solid knowledge of libraries I use. If I'm really stuck, I opened 3d party github, and scan issues, to see if there's something similiar. Lots of times there is issue or something, but I'll admit, lots of time there isn't. This is when I start googling, which sometimes take me to Stackoverflow. If not, I use gitter to ask authors. But this happen very rarely. Mostly all I need to do is dictated by library types I use. Occasionally, with shitty libraries that bring external configuration I have to check their docs on github. But I think it may be language related. Or experience perhaps. I had to do a bit of javascript with node.js (2 weeks +-), and I visited SO very very very often. Normally whenever I'm learning new language or framework, navigating to sources is my fasttrack to both language and framework/lib. There isn't a better way to learn what's right way to do stuff than to see authors of battle tested libraries solving difficult problems, and learning from their style. I can recommend that :) I'll admit your mileage may vary, and this may be specific to my job, but I'm pretty happy with this workflow, and I don't have anything against people using SO or something. Edit: I had forgotten important part - occasionally I spin REPL and try what library really does there. But that's also one of last resorts, when I'm stuck :) In Scala we have http://www.lihaoyi.com/Ammonite/ http://www.lihaoyi.com/Ammonite/ which makes it super easy to fetch and use external dependencies etc... so I guess tooling is also important part.