That’s why I usually starts with the simplest version of something I want, which is usually a shell or a perl script. When I nailed down my workflows and needs, that’s when I build a proper program. This is one of the reason I like cli programs. They’re like lego blocks for workflows.
Same things with bigger projects. Write the most minimalistic version of a feature, and then ship it (or do a round of testing). Iterate based on feedback.
It may not be an abstraction of a real machine. But the C abstract machine is very close to the foundational idea of how a computer work. And it’s quite easy to bootstrap.
Importantly my work involves me often being able to look at C and think about the assembly and back and I regularly work on ESP32, ch42(riscv) and atmega avr8.
I couldn't do that with mciropython on any platform.
My opinion is that Lisp and Smalltalk are too pure and abstract. C is heavily tied to the real world of computing and can be easier to grasp for beginner. But try to explain variable bindings (instead of assignment) or message passing (instead of function calls) to a beginner in programming. It’s not that they’re hard to explain or understand, they’re just hard to be completely grasped without a foundation in computer science. They’re too alien.
Mine is “ticket id - Imperative phrase”. Then I write a “why” description of the changes if needs be. As for personal project, I quite like the scoped commits style.
Code was never the main effort of work, but it was a clear signal that someone has done the main effort, which is understanding the codebase, designing a new feature, or investigating a bug, and have the knowledge to write the code. By the time you get to review, you can expect a knowledgeable person on the other end.
It’s the same about published journal article. A lot of them are a few pages. That is mostly one hour of typing. But everyone knows that typing it is not the work.
Right, and all of that is what I consider to be the "code" effort:
Deep research in the codebase, deciding on the flavor of code to write that matches the project, deciding how you'll model the feature with types, how to architect it so that it's testable, writing the tests, foreseeing cases beyond the obvious path, etc.
What changed is that it can be automated. Or, just grant a world where AI is perfect at implementation.
Now our time/energy/attention is freed up to concentrate the work around planning what to build. And the interesting part is that it becomes the input into the AI implementor.
This is a good thing since we tended to skip the planning stage since it's hard in its own way. Or we start building something and then try to synthesize a high level direction from it, yet now since refactoring is so expensive, we're committed to a solution.
Experience as in numbers of years or project participation is flawed. But experience as in contributions and knowledge of some specific domains is good IMO.
It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.
> It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed
I never trust my own code. And one of the motivations of trying to be fluent with my editor, is to be able to quickly look at it when a bug is reported. I also don’t trust another person with their description of their code. Any surprise, and I’m looking at the source if it’s a available.
> You can start typing, cancel, retry with previous input, accumulate messages while the agent is active. I don't know all TUIs but this is not common IMO.
Literally every audio player or anything that uses threads.
good point, i didn't classify tui audio players in a way, they don't converse, they allow asynchronous effects and stacking, that said i might be lagging about these, last i used was mocp, any names i should check out ?
I wouldn’t trade the hours I spent with a group of friends in front of a n64, and a handful of multiplayer games (shooter, fighting, and racing). It was us 4 to 8 kids for 2 controllers. While I play a handful of PC games and have a console, there’s nothing better than a good living room session.
Same things with bigger projects. Write the most minimalistic version of a feature, and then ship it (or do a round of testing). Iterate based on feedback.
reply