81–90 of 320 posts
Can't find any fault in this article. Agree with pretty much everything except for one point: "Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written." It has been, I think, close to 15+ years since I have been actively coding professionally. I am always learning. When I started my career I spent a fair bit of time answerin…
Earlier quoted context omitted.
> Note that this says "best programmers" not "people best at having business impact by making software". We can look at a software developer as a craftsperson, and appreciate their skill and their craft, and we can look at them as a business asset, and those are two different things. Both of which have their merits, but this article is clearly focused on the craftsperson side and that's enough. We don't need to make…
I’m retired, these days, and spend the majority of every day, writing software. I treat it as a craft, and do it for personal fulfillment and learning. I enjoy learning, and solving problems. I also enjoy creating stuff that I find aesthetically pleasing. For example, I write iOS apps, and I’m working on a new version of a timer app that I’ve had in the App Store, for over a decade. I had added a Watch app to it, and…
https://web.archive.org/web/20250409082704/https://endler.de... Otherwise rate limited
wondering how can a static blog can be rate limited :|
Reading documentation - if you are junior take time to go one level deeper to understand / fix issues you have. Then read also stuff adjacent to that. By trying to read some documentation like a book from cover to cover will be waste of time.
Reading documentation cover to cover for tools you use a lot is a very worthwhile investment in my opinion. Junior dev or not.
There is no "only SO and LLM shortest path" vs "always read full documentation" - there are always more sources like blog posts, walk troughs that will be much better investment of time.
Sometimes you need someone to explain architecture of the tool much differently than it is described in documentation when documentation is dry. Sometimes you need better examples better aligned to what you are trying to do. You need different approaches to grasp the thing.
A guess might be your best opportunity to test a theory about a bug you don't understand. That's particularly true where you're a newcomer to an area and the documentation is written for someone with different experience.
A series of guesses and tests can narrow down the problem, and ultimately help you fix a bug on your own terms, a bit like tracer fire.
I much _prefer_ to build a mental model, and to spot the bug as a deviation from that model. And unguided guesswork can be a sign that you're flailing. But guessing can be a strategy to build that model.
This is great advice. Unfortunately, all these AI tools make it far too easy for beginners to not follow it. I'm not sure if all this advice will become irrelevant or if those programmers trained in the 2020ies will not become those "best"..
I'm kinda conflicted that you shouldn't use AI. With a good combination of Cursor, NotebookLM, flashcards (I use RemNote) and practicing you can accelerate a lot your learning. Nothing stops you from reading specs, docs and having AI assist you doing so.
I understand the power of flash cards and SRS in general. But was wondering how you decide when to put something into an SRS when learning something new. Especially in a tech/programming context.
> Don’t Guess
If you work with anything but a very simple program, you often must guess what could be the cause(s) of your issue in order to know where to look. The more experienced you are, the more accurate your guesses will be.
Earlier quoted context omitted.
wondering how can a static blog can be rate limited :|
Cloudflare claims that Pages allow unlimited traffic [0]. So it seems like author is using Workers, probably on a free plan. [0]: https://www.cloudflare.com/plans/developer-platform/