This could use with being a bit shorter and maybe carved into pieces because the main idea is very powerful and the author has seen a thing or two clearly!<p>That being said although I agree with many things the author said, I think this phase goes a bit different:<p>> "You will waste so much time! Let's have a grand plan and write the perfect solution right from the start, ehh?"<p>The reason why bosses/ non technical people want to talk so much before and write so much non-code is because they can. If they could write code they wouldn't mind , but the "talking" phase is the only one where they can contribute and so to feel useful they actually delay everything.<p>This comes from an observation that difficult problems / projects sometimes were fixed much faster than easier problems.<p>Why? Because an easy problem is understood by everyone, so everyone has an opinion, so now we have to hear all the uninformed opinions and debate all the obviously-not gonna-works. But hard problems, they have two great properties, most people won't even understand the problem, and even if they do, they won't know what to do. So then you get one or two guys to actually fix it undisturbed.<p>Not only it's slower to have to deal with uninformed opinions, the outcome is often worse also, because for politeness and to avoid awkwardness you end up with an "average" of the opinions, but if majority of those are uninformed you just got a worse solution by talking.
How do you know you're building the right thing? Who is paying your salary? Are you regularly talking to all stakeholders? Congrats, now most of your time is spent in meetings. You don't want that? Now you have to talk to project and product managers, who don't want to reinvent the wheel and thus impose structured information exchanges like planning on different time horizons (sprints, quarterly roadmaps, ..).
I agree with some of what the author says (building at least one prototype before carving a plan into stone is usually a great idea), but I think affordances for teamwork are missing. The author proudly reiterates how much of their development process exists only locally, with key artifacts like mocks and prototypes being inaccessible to team members. I think one of the most effective ways to increase velocity is to structure your work so that 2-3 other people can work on it with you. I feel like that would be a more productive discussion than some of the nuts and bolts stuff this article dives into (side effects or ifElses or what have you).
> Yet, the alternative, the rich man's debugger, introduces another tool into the project, something I try to avoid<p>I would not call this introducing a tool into the project. The debugger is not part of the project. I would call this utilizing the tools that are already built into your editor to make yourself more productive, instead of kneecapping yourself to only printing things.<p>Talking to the main point of that paragraph - using a debugger and having hot reloads are not mutually exclusive. You can use hot reloads to rapidly see live changes, then use breakpoints to inspect state if required. Additionally, that a debugger "cannot change the implementation" is not universally true; this varies by language and debugger, see Erlang/Elixir.<p>When people say things like this, it makes me think they simply lack the knowledge on how to effectively use a debugger, or they (or their language ecosystem) have not invested in good tooling.
one thing i’d add that works well in javascript that is similar to “eye level is buy level”<p>and that is “hoist the system”<p>the important things that any file does is at the top.<p>the things those things depend on are either imported from packages at the top of the file or hoisted from functions below.<p>the things those functions depend on are hoisted from below them and so on<p>this makes every file in a system easy to grok because the first things are the business needs and as you scroll down, you get into the weeds and the implementation details— important things, but conversationally irrelevant things— this paradigm makes cross functional collaboration more effective as it drives engineers to understand business context with literal forcing functions.