4 ms·

It is a bit more complicated, as it can be harmful for experts also, and the more reliable it gets the more problematic it becomes. Humans suffer from automati

It is a bit more complicated, as it can be harmful for experts also, and the more reliable it gets the more problematic it becomes. Humans suffer from automation bias and other cognitive biases. Anything that causes disengagement from a process can be challenging, especially with long term maintainability and architectural erosion, which is mostly what I actively search for to try and avoid complacency with these tools. But it takes active effort to avoid for all humans. IMHO, writing the actual code has always been less of an issue than focusing on domain needs, details, and maintainability. As distrusting automation is unfortunately one of the best methods of fighting automation bias I do try to balance encouraging junior individuals to use tools that boost productivity while making sure they still maintain ownership of the delivered product. If you use the red-green refactor method, avoiding generative tools for the test and refactor steps seems to work. But selling TDD in general can be challenging especially with Holmström's theorem, and the tendency of people to write implementation tests vs focusing on domain needs. It is a bit of a paradox that the better the tools become, the higher the risk is, but I would encourage people to try the above, just don't make the mistake of copying the prompts required to get from red to green as the domain tests, there is a serious risk of coupling to the prompts. We will see if this works for me long term, but I do think beginners manually refactoring with though could be an accelerator. But only with intentionally focusing on learning why over time.

nonrandomstring 2y ago
> It is a bit of a paradox that the better the tools become, the higher the risk is "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off". -- Bjarne Stroustrup
faizshah 2y ago
I completely reject this way of thinking. I remember when I was starting out it was popular to say you learn less by using an IDE and you should just use a text editor because you never learn how the system works if you rely on a run button or debug button or a WYSIWYG editor. Well in modern software we stand on the shoulders of many many giants, you have to start somewhere. Some things you may never need to learn (like say learning git at a deep level when learning the concept of add, commit, rebase, pull, push, cherry pick and reset are enough even if you use a GUI to do it) and some thins you might invest in over time (like learning things about your OS so you can optimize performance). The way you use automation effectively is to automate the things you don’t want to learn about and work on the things you do want to learn about. If you’re a backend dev who wants to learn how to write an API in Actix go ahead and copy paste some ChatGPT code, you just need to learn the shape of the API and the language first. If you’re a rust dev who wants to learn how Actix works don’t just copy and paste the code, get ChatGPT to give you a tutorial and then your write your API and use the docs yourself.
- yoyohello13 2y ago
  Using an IDE does stunt learning though. Whether that’s a problem is up for debate. But relying on the run button, or auto completion does offload the need to remember how the cli fits together or learn library apis .
  - faizshah 2y ago
    Do you have any evidence of that? From personal experience and from the popularity of rstudio, jupyter etc. the evidence points in the other direction. It’s because when you start out you just need to learn what code looks like, how does it run (do all the lines execute at once or sequentially), that you have these boxes that can hold values etc.
  - FridgeSeal 2y ago
    Given that form most of my projects, the run button is a convenient wrapper over “cargo run” or “cargo test — test-name”, or “python file.py” not super convinced of the argument. Maybe in C/C++ where build systems are some kind of lovecraftian nightmare?
    - jwrallie 2y ago
      Some Makefile knowledge does not hurt much, but other than that it starts to become a nightmare. Another big difference is the size of the standard library. One can hold on his brain all the information needed to program in C, but I would argue that for C++ or Java it would be too taxing and an IDE is almost a requirement, the alternative being consulting the documentation often.
    - kazinator 2y ago
      It's actually this language-specific packaging ghettos that exist precisely in order to hide the grotesque reality of how difficult it is to directly use third party code in these languages. People making new languages should resist this trend. Do not implement another damn package manager. Think about the problem and make it easy for people to just use someone's tarball of code.
- 2y ago

nonrandomstring 2y ago

> It is a bit of a paradox that the better the tools become, the higher the risk is "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off". -- Bjarne Stroustrup

faizshah 2y ago

I completely reject this way of thinking. I remember when I was starting out it was popular to say you learn less by using an IDE and you should just use a text editor because you never learn how the system works if you rely on a run button or debug button or a WYSIWYG editor. Well in modern software we stand on the shoulders of many many giants, you have to start somewhere. Some things you may never need to learn (like say learning git at a deep level when learning the concept of add, commit, rebase, pull, push, cherry pick and reset are enough even if you use a GUI to do it) and some thins you might invest in over time (like learning things about your OS so you can optimize performance). The way you use automation effectively is to automate the things you don’t want to learn about and work on the things you do want to learn about. If you’re a backend dev who wants to learn how to write an API in Actix go ahead and copy paste some ChatGPT code, you just need to learn the shape of the API and the language first. If you’re a rust dev who wants to learn how Actix works don’t just copy and paste the code, get ChatGPT to give you a tutorial and then your write your API and use the docs yourself.

yoyohello13 2y ago
Using an IDE does stunt learning though. Whether that’s a problem is up for debate. But relying on the run button, or auto completion does offload the need to remember how the cli fits together or learn library apis .
- faizshah 2y ago
  Do you have any evidence of that? From personal experience and from the popularity of rstudio, jupyter etc. the evidence points in the other direction. It’s because when you start out you just need to learn what code looks like, how does it run (do all the lines execute at once or sequentially), that you have these boxes that can hold values etc.
- FridgeSeal 2y ago
  Given that form most of my projects, the run button is a convenient wrapper over “cargo run” or “cargo test — test-name”, or “python file.py” not super convinced of the argument. Maybe in C/C++ where build systems are some kind of lovecraftian nightmare?
  - jwrallie 2y ago
    Some Makefile knowledge does not hurt much, but other than that it starts to become a nightmare. Another big difference is the size of the standard library. One can hold on his brain all the information needed to program in C, but I would argue that for C++ or Java it would be too taxing and an IDE is almost a requirement, the alternative being consulting the documentation often.
  - kazinator 2y ago
    It's actually this language-specific packaging ghettos that exist precisely in order to hide the grotesque reality of how difficult it is to directly use third party code in these languages. People making new languages should resist this trend. Do not implement another damn package manager. Think about the problem and make it easy for people to just use someone's tarball of code.
2y ago