Why would you use a library or framework when you can code everything from scratch? It probably depends on how good the VSCode extension is vs how bad the IDE is.

For the languages I have tried (mostly GoLang plus a bit of Terraform/Terragrunt), VSCode plugins can do code highlighting, can highlight syntax and lint errors, can navigate to a methods implementation, the auto-complete seems to pick random words from the code base, and can find the callers for a method. It is good enough for every day use.

IDEs I have used (Eclipse for Java, PyCharm, InteliJ for Kotlin) offer more. They all have starter templates for common file types. The auto-complete is much more syntax aware and can sometimes guess what variables I intend to pass in as arguments. There is refactoring which can correctly find other usages of a variable and can make trivial code rewrites. There are generators for boilerplate methods. They all have a built in graphical debugger and a test runner.

TAOCS has a reputation for being very deep and thorough, not for being a good introductory text. One of my professors said that in his (very long) industrial career, he only met one person who actually read the books beginning to end but everyone looks something up in them once or twice.

That has been my experience. I once needed to find out how to solve a very specific problem (I think it was calculating statistical values on an infinite stream). I found the single copy of TAOCS in the office reference library, read the relevant section, and implemented the suggested algorithm.

C does exactly what you tell it, no more. Why waste cycles setting a variable to a zero state when a correct program will set it to whatever initial state it expects? It is not user friendly, but it is performant.

The early days of the Internet, there was a cottage industry to burn Linux ISOs to CDs and selling them.

I am well aware of learning, but people tend to learn by comprehension and understanding. Completing phrases without understanding the language (or the concept of language) is the realm of LLM and Scrabble players.

• Encrypt the data at rest
• Encrypt the data in transit

Did you remember to plan for a zero downtime encryption key rotation?

• No shared accounts at any level of access

Did you know when account passwords expire? Have you thought about password rotation?

• Full logging of access and activity.

That sounds like a good practice until you have 20 (or even 2000) backend server requests per end user operation.

All of those are taken from my experience.

Security is like an invasive medical procedure: it is very painful in the short term but prevents dire complications in the long term.

I have been an individual contributor at large corporations for more than 10 years. Every time I have had a colleague promoted to manager, they always planned to stay technical and keep coding. Every one of them, without fail, stopped coding because they were too busy.

Thinking back to my managers who left for other roles, only one quit to work in higher management, the rest all went back to working as developers.

I worked at giant, globally distributed companies (15-25k employees), so I imagine that my experience is not typical.

But a floating point issue is the exact type of issue a LLM would make (it does not understand what a floating point number is and why you should treat them differently). To be fair, a junior developer would make the same type of mistake.

A junior developer is, hopefully, being mentored by more senior coworkers who are extra careful with code reviews and would spot the bug for the dev. Machine generated code needs an even higher level of scrutiny.

It is relatively easy to teach a junior developer to write code that is easy to read and conforms to the teams style guide.

All the time. Causes include:

• Test depends on an external system (database, package manager)
• Race conditions
• Failing the test cleared bad state (test expects test data not to be in the system and clears it when it exits)
• Failing test set up unknown prerequisite (Build 2 tests depends on changes in Build 1 but build system built them out of order)
• External forces messing with the test runner (test machine going to sleep or running out of resources)

We call those "flaky tests" and only fail a build if a given test cannot pass after 2 retries. (We also flag the test runs for manual review)

I also like checked exceptions. I like having a compile time check that I thought through error scenarios.

Is it perfect? No, but it should be iterated upon, not discarded.

FYI, catching and rethrowing as an unchecked exception is a pretty bad anti-patern (and a foul code smell).

I have tried GitHub project boards for hobby repos and was disappointed by how bare bones it was. For example, it did not have support for breaking a story into smaller component stories (like a Jira Epic or task with sub-tasks).

My favorite YOLO-Driven Development practice (from a former employer) was Customers as QA. We would write code, build the code, and ship it to the customer, then the customer would run the code, file bugs for what broke, and we would have a new build ready next week.

It provides many benefits:

• No need to hire QA engineers.
• Focuses developer debugging time on features actually used by customers instead of corner cases that no customer is hitting.
• Developers deliver features faster instead of wasting time writing automated tests.
• Builds are faster because "test" stages are no-op.

One time a developer was caught writing automated tests (was not sure in the correctness of his code, a sign of a poor developer). Our manager took 15 minutes out of his busy day to yell at him about wasting company resources and putting release timelines in jeopardy.