> The truth is that no one in management cares about your perfect code, they only care about the projects you deliver, the features you push out and the meeting KPIS.. Your customers don't care about your perfect abstractions either, they just want the button to work when it's clicked.
I don't think most developers care about perfect code (if such thing exists). What they care about is maintainability, so that the project is delivered on time, features keep getting pushed and KPIS can be actually met. And that the customers have a working button.
Instead we got projects that keeps being dragged around (until it's put out of its misery), half baked features, and KPIs that are twisted until they're barely looks like what was stated at the beginning of the quarter. And the customer is complaining about another button breaking.
What I do is never ask for permission, because that's an engineering concern, not a product/management one. I just tidy the code I work on, one step at a time.
If there's one thing I've remarked, even before LLM tooling, is that there's a class of people that is ready to try things for weeks until it magically work (with no guarantee it will hold), instead of spending one hour designing it and formalizing it. They won't get functional abstraction, maintainability means nothing to them, and architecture don't matter.
They're the one copy-pasting straight from StackOverflow, and if it does not work, will copy-paste something over it. When something works, they will copy-paste it all over the codebase regardless of context.
For those people, LLM tooling are the Second Coming. Because it helps them eliminate all the telltale signs of bad works they've been doing. For them, "Use the AI" is the new mantra because they can't imagine not needing to use it.
> The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
With Vim, Emacs, Git,... there's a core concept that all those extras get backs to. The issue with normal editor is that their concept of a text file is an array of lines of characters. Some goes further with providing some parsing to further isolate things like strings or symbols.
With Vim, there's the buffer (aka the content), the window (where user view the content), the cursor (which is the point of origin of many actions) and various commands that moves the cursor according to what's in the buffer. Like with the hand, you can draw, write, make dough, play the piano,..., you use the same hand, you don't have to replace it to do any other actions, you only taught yourself how to do it.
Same with git. It has a core concept that encapsulate everything to do with versioning text files, you just have to compose them to do what you want.
This kind of conceptual simplicity, even though the interfacing may be rough, is good because you are solving classes of problems instead of solving them one at time. For a particular problem, you only need to switch configurations, not to learn a new tool.
The issue is when you tackle a bunch of features not related to each other, or simplify the model so much that it's a toy instead of a tool.
> That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it
I do not disagree with that
> When you do a macro, you have to try and get it right, and then try again from the start each time to get it right.
But you are wrong in that, because you assume that visual feedbacks are necessary. They are useful. Using vim and the likes is very much like playing the piano or driving a car. You’re always one step ahead of your actions because translating intent into operations is effortless as they are ingrained in muscle memories. I don’t even look at the cursor much of the time because it will be where I need it. I don’t care for mistakes because they are easily corrected.
Even then, I rarely use macros because they are at the high end of the power spectrum. Only writing your own commands is higher on the list. Easy macros are easy to create, powerful macros are created only when necessary and are worth the carefulness. I don’t think there’s something similar to named registers and emacs counters with multiple cursors solutions. Or the ability to have multiple macros ready to go at anytime (very useful for data cleanup).
One of the things about Emacs and Vim is that you have commands that does things. They all have the same conceptual model. In vim, you have the text objects, the motions, and the counts (and more advanced ones like line and pattern addressing). In emacs, you have the point, the mark, and the arguments (including the universal one) (the advanced ones are which modes are currently active). That’s mostly the internal state that matters when you think about an edit which changes A to B.
You think about the evolution of the internal state and the suitable commands just appears, just like you think of an idea and the suitable words appears. Learning commands is like expanding your vocabulary, not learning how to speak. Learning how to speak is internalizing the aforementioned conceptual model.
The things about multiple cursors is that you think about the processing while doing it, while most people using macros looks at the structure of the text first and then devise the macro. I wouldn’t say the latter is faster, but it’s a different mindset.
And the other thing is that vim has the “dot” command to repeat your last edit. Similar to macros, you think about your local edit first, then about where to repeat it (usually tied to the next item in the search list).
Edit (after reading the article).
Both vim and emacs (which have the steep learning curve) are aimed at power users. It’s best to compare them to professional tools like CAD, DAW, industrial appliances,… The friction when learning is because a lot of users don’t know what’s possible to do or even have the kind of problems that experienced users do (or they fail to perceive them as issues). After a while, it becomes like an extension of your thinking and the tool disappears.
Drawing/Painting and Cad modeling is very much like games. One hand on the keyboard and the other on the mouse. This mixture can be also done well in other programs. I only bother learning shortcuts for daily tools, not something I use every blue moon.
What I take issue is with tools that make them hard to use with low contrast between widgets or shortcuts that does not work if a text input is focused. Also tools that forget they have a primary usage and wants me to know everything at once (notifications, big action buttons, guided tours and what not).
The Emacs API is kinda huge, with things like very raw network API, a very good approximation of fork/exec process management, buffers as the base communication mechanism with a lot of capabilities, various utility function with regards to interfacing with the user (windows, frame, faces, keyboard events), then the hooks and advice subsystem.
With Unix, most programs are binary and while the shell is a good glue language, you can’t alter a program and the OS that much. With Emacs, only the core coded in C is sacred, anything else can be modified to fit your workflow. And there’s a lot of packages out there to provide you with raw materials.
Yep, you have to use C# and Java because they are safe. If you want anything extra, you need to use $library, because only $library's maintainer is trusted with the dark corners of the language. Look how powerful we are, millions of libraries. Look at those Lisp guys and their sorry examples of package managers. /s
If there's one thing I've been happy with learning Common Lisp and Clojure is that you only want libraries for things like algorithms, data formats, and protocols/interfaces. Mostly because those often have standards. Anything else should be a snippet to copypaste even when presented as a full program.
The reason people don't bother with specs is that they're extraordinarily verbose, ambiguous, and simplistic at the same time. Which is why we have invented formal notations, because they're short, have one definition, and enough to create the whole thing, if not to understand the why. The latter can still be done in prose.
What a spec is truly useful for is that it lets you manipulate the solution at the idea stage, without tainting it with real world concerns. But to do it requires a lot knowledge about those real world concerns, so that your assumptions are not straight lies.
This is good for iteration. But any implementation ossifies your specs, and while code are more malleable than most, there's a certain points when the specs should be discarded and the actual implementation being the source of truth for any further development. In any project, that is done with Change Request, which only outline the specific area of changes, assuming the rest as being immutable.
> AI does not "restart from scratch everytime", it takes an updated spec plus existing code and updates the code to match the updated spec.
Maybe you can share an example of that workflow and an actual argument that would make it sustainable.
I've written the formal version of a spec (a suite of tests) and if there's one thing that would make the above idea ridiculous is how much wiggle room there is to follow the specs and be at the same time unusable.
> The whole point here is that you don't change the code, you change the specs,
> but doesn't encapsulate anything about the spirit or purpose of why the design in a certain way. Good specs do.
Specs are meta solutions. They describe the general shape of the solutions by refusing to make any technical decision that would leads to incidental problems and thus only needs to focus on the essential ones. So they're always simplistic, because they ignore the cascading effect of implementation decisions.
Generating code with AI is rolling the dice every time said generation is done. Proper implementation happens because with making decisions and going down a path, backtracking if necessary when it's no longer working. Going with AI is breaking down that continuity because they restart from scratch everytime.
Always have been. When something is your primary tool, you develop strong opinion about it. Code is notation, helping to describe solutions. Not everyone thinks and solve the same way, so strong preferences is not unusual.
Not really, I don't think I've ever care about the how. I want to mostly know the trigger of a change (a bug, possible feature, or just tidying) and what are the impacts if that changes is included in the codebase. That is often just a paragraph or two.
The workflow is mostly worthless, unless it can generalize and evolve into a process. And that is more worthy of a blog post or a presentation.
Nowadays, I’m mostly interacting with open source components, so I read source code when the docs are lacking. I rarely have questions in the form of “How do I do…”. They are mostly “How does this thing work?”
Not really, as you always need to check back on your assertions, especially at the boundary points where information about types and ownership are more axiomatic than the result of logical inference.
The “clankers” won’t take over, but have you also noticed that most people are talking about their workflows/process instead of their results/outcomes? It’s all about “Is the train still running?” than “Are we getting close to the destination?”.
I don't think most developers care about perfect code (if such thing exists). What they care about is maintainability, so that the project is delivered on time, features keep getting pushed and KPIS can be actually met. And that the customers have a working button.
Instead we got projects that keeps being dragged around (until it's put out of its misery), half baked features, and KPIs that are twisted until they're barely looks like what was stated at the beginning of the quarter. And the customer is complaining about another button breaking.
What I do is never ask for permission, because that's an engineering concern, not a product/management one. I just tidy the code I work on, one step at a time.