I use terminal commands to open relevant ide for the project

Having a bunch of plugins built-in means also supported in updates and play nice with each other

I also had issue when I was working on a pycharm project back when I was on windows. During setup it asked me “What’s your name?” and my name has a cheeky accent which Windows was decided should be the name of my Home folder. Home folder also has appdata and whatnon so which the build system didn’t expect to have a an accent in the folder path.

I ended up having to create a different folder and link to it then move all the path configurations to that folder link just so I could get imports working.

I use Jetbrains IDEs now for 5 years, I’ve used VSCode, Sublime, Atom, Vim, Neovim but I feel like Jetbrains IDEs are just better if you have the RAM to run it.

1. It’s a setting.
2. Doesn’t happen
3. Doesn’t happen
4. Searchable actions, just search for “encoding” in this case.
5. That’s an LSP/project mismatch usually just a setting. Most things are supported but worst case you can remove the error.
6. Happens if you run out of RAM or open a very large file.

So it’s not all bad, but comes with a lot of good such as “invert if statement”, “use template strings” and “extract method” thingies along with a load of plugins.

It’s a common practice but not required. Python behaves like JS where it just runs whatever you wrote. If you don’t want it to run when importing the file you can put the main() inside the if so it only runs when you run the actual file.

You can use it when developing a function or a class to run a simple test without running the whole program.

Bash combines quick, dirty and fast in exchange for readable. Bash is also nice for terminal functions like opening a set of programs and whatever

Don’t get me wrong, I still write more than 98% of code by hand and of course, I can write those functions myself in 30m myself but I can get it in 60s with the AI. LLMs can write code to that does parse - > model - > map - > format with only one or two easy to fix bugs.

It’s in the very niche cases where it’s just tedious to write something out that LLMs actually work. “Write an API client that uses [library] that handles these requests/responses” comes also to mind as something that would work.

I’m using now also to learn react native where I get bugs I’m very unfamiliar with and SO doesn’t give me a good answer.

I’ve also had decent success at having it review my code with “how would I further optimise this code” and it gives me some pointers and then writes buggy code but the approach is correct usually and I can implement it myself.

These AIs really suck at writing correct code but I’ve had good success in having them write code generators. I recently made it write a script that takes a SQL create table statement and converts in to TS and gives insert update, delete and whatnot and also creates a simple class that handles the operations.

I had to write the original code by hand but having it write code that writes boilerplate which I correct is pretty good.

Other code is hit or miss IMO

He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.

Some really good points he makes are for example:

• Functions that only do one job
• Testing makes refactoring easier
• The standard SOLID OOP stuff.
• Tech debt is bad
• Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
• Insulate yourself from change
• Duplication is bad
• Two use cases that are very similar is not duplication and common code shouldn’t be factored out.
• Don’t mix high level code with low level.
• Build solid Entity classes to model the data and their interactions.
• Don’t write multithreaded code if you don’t have to.
• If you have to do your best to write it so they don’t share memory.

Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:

• Refactoring is expensive and the cost is often not justified.
• Premature abstraction is the absolute devil
• You don’t need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
• Less changes also lead to less bugs.
• Too much emphasis on functions being few lines of code instead of just being simple.

All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.

In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.