Until you know a few very different languages, you don’t know what a good language is, so just relax on having opinions about which languages are better. You don’t need those opinions. They just get in your way.

Don’t even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined … but that was wrong. JavaScript is fine, C# is fine … as long as you don’t stop there.

(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney’s first published game, back when Epic Games was called Potomac Computer Systems. It doesn’t have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn’t cause brain damage, no language will.)

Please don’t say the new language you’re being asked to learn is “unintuitive”. That’s just a rude word for “not yet familiar to me”. So what if the first language you used required curly braces, and the next one you learn doesn’t? So what if type inference means that you don’t have to write int on your ints? You’ll get used to it.

You learned how to use curly braces, and you’ll learn how to use something else too. You’re smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are “unintuitive” rather than merely temporarily unfamiliar is just getting in your way.

Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It’s like the assembly of type systems, except it makes your program slower instead of faster.

In unit testing, a “unit” does not have to be the smallest possible section of code. It can be a while class or module or even set of related classes/modules. Testing individual functions in isolation leads to brittle tests that easily break during refactoring. Testing overall system behaviour results in more robust tests that require fewer changes during refactoring which gives you more confidence then you have not introduced a regression.

Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.

Dynamically typed languages don’t scale. Large project bases become hard to maintain, read and refactor.

Basic type errors which should be found in compilation become runtime errors or unexpected behavior.

You can always solve a problem by adding more layers of abstraction. Good software design isn’t to add more layers of abstractions, it’s to solve problems with the minimum amount of abstractions necessary while still having maintainable, scalable code.

There are benefits to abstraction but they also have downsides. They can complicate code and make code harder to read.

You can use all the classes, patterns, functions, methods you want but if it’s not readable it’s garbage.

Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.

Its ok to have more advanced topic that require more knowledge and that people don’t understand from the first moment they see them.

Everybody trashing on code reviews has never worked with a shit coder before

I’m a shit coder and almost every single review I’ve made big mistakes like forgetting to delete debug/dead code and there’s always meaningful improvements being suggested

If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.

Shorter code is almost always better.

Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.

A nice thing about code length is it’s objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.

It takes a damn good abstraction to beat having shorter code.

The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.

Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.

Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.

Unit testing is often overrated. It is not good for discovering or protecting against most bugs.

Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.

Using single character variable names is always bad practice

Programing is a lot less important than people and team dynamics

Most modern software is way too complex for what it actually does.