The whole "integrated development" experience. Take it or leave it, but old farts like me go all the way back to poring over code on printouts since your only window into it was one file at a time in an 80x25 terminal - not terminal window, actual terminal or, by then, terminal emulator.
That does affect later habits like, for example, hating the information overload from syntax highlighting. And don't even get me started on auto-indent.
Whereas younger colleagues, whose habits were formed in the era of much more sophisticated tools, have dozens of files open in tabs and can follow, say, a "where is this defined" or "where is this driven" (this is RTL code, not normal software) in an instant. Keep in mind some oldtimers had really fancy emacs setups that could do that, and vi users had things like ctags.
I agree with this. I've been able to tackle projects I've been wanting to for ages with LLMs because they let me focus on abstractions first and get over the friction of starting the project.
Once I get my footing, I can use them to generate more and more specialized code and ultimately get to a place where the code is good.
I appreciate this way of programming - also, if I may, in the age of auto-complete I think it's okay to have verbose variable naming. Imho, it's perfectly fine to have quad, quadVelocity, dragMagnitude, etc.
I see this a lot in the wild, though - as an honest question (not trolling!) why do people still shorten their variable names in place of having a terse descriptor ?
I tend to have shorter names for function scoped variables. Wider the scope - more descriptive the name. Short names are good to have more concise code and more logic fitting into a line width.
Currently working on a code formatter and parser for Supercollider's sclang.
Supercollider is an amazing language, but the development tooling is severely lacking - we need good tooling, and now with LLMs in play and my coding ability leveled up from doing GATech's OMSCS, I'm finally able to tackle this.
I'm learning rust while I'm doing this too, so it's been an experience. Fun, though.
This isn't made by developers, that's clear, and I don't think it's going to be very functional. However, I do love the aesthetic and I do love that someone is trying something new.
By new you mean they’re making a 1980s all-in-one keyboard/computer with the 10 key on the wrong side of the keyboard running a version of a familiar-to-most-of-us OS that isn’t at all new looking?
I’m sorry; none of this is new to me except the absurd price tag.
While I agree with your general sentiment, the 10 key being on the "wrong" side could be good, perhaps, in some cases?
Historically I've done some heavy spreadsheet work where the resting position of my hands which minimizes movement is right hand on the mouse, left hand on the 10 keys. On a normal keyboard that has the disadvantage of causing a "closed" posture which isn't entirely comfortable.
Outside of that kind of niche use case though, it definitely feels like a strange choice for developers.
10,000% this. Attaching JIRA tickets, etc. to the commit helps for searching as well. I've worked with a number of people who do not believe in this and it drives me insane ; I try to enforce it, but there's a lot of messages like "fixed bug" that have zero context or detail associated with them.
I don't understand why so many engineers are like this.
Attaching JIRA issues makes a ton of sense for features that are described in JIRA. If we're talking about a bug that was found by a developer, unmotivated by a ticket, it would generally make more sense to just describe the bug directly in the commit message. This is of course not true if the JIRA tickets are used for something else downstream, like informing users of fixed bugs, or tracking changes.
The other issue with tagging JIRA tickets is that junior developers will believe that to be enough (you can just read the ticket) and wont understand why they need to describe the change from a technical angle, when it's already described in JIRA.
Commit messages are immutable. Linking them to a bug ticket gives you a mutable place to record any new information about the bug that you discover in the future. (For example, that it affected more cases than you originally thought, or that the fix caused another bug.) This new information will be discoverable when starting from the original commit (found e.g. by doing a blame on a particular line of source).
To fail to do so is a gigantic missed opportunity in my opinion. You never know when you will need it.
Attaching ticket numbers has always been enforced by automated checks wherever I have worked, so it is not necessary to “try” to enforce it.
Similarly with AI it is fairly simple to have eg a pre-merge check that validates the commit msg is somewhat useful. This could be implemented for example with GitHub org level checks that must run in a PR.
My preferred way of doing PRs/Code Review echoes some of the statements below, but also requires the engineer to do the following:
1) Each PR (even if it's part of a larger whole) can be committed and released independently.
2) Each PR has a description of what it's doing, why it's doing what it's doing, and if it's part of a larger whole, how it fits into the broader narrative.
3) PRs are focused - meaning that QOL or minor bugfixes should not be part of a change that is tackling something else.
4) PRs are as small as possible to cover the issue at hand.
5) All PRs are tested and testing evidence is presented.
6) When a PR is committed to master, the final narrative in step 1) is the Git commit, along with the testing evidence, includes the JIRA ticket number in the headline, and the reviewer in the body of the git commit.
This way we have a clean, auditable, searchable history with meaningful commit history that can help reconstruct the narrative of a change and be used as a guide when looking at a change in, say, a year.
I agree with this up to a point - having consistent code style with some sort of formatter (gofmt, black, clang-format) goes a long way to reducing complexity of understanding because it unifies visual style.
I suggest that a codebase should read like a newspaper. While there is room for op-eds in the paper, it's not all op-eds, everything else should read as a single voice.
My experience is that projects which value code formatters (and similar rulemaking) tend strongly not to have room for "op-eds", FWIW. And conversely the code bases I've seen with the best/cleanest/most-clearly-expressive code tend strongly to be the ones with fewer rules.
I think the one exception there is in some open source contexts (Linux is the archetype) which receive a fire hose of submissions of questionable quality and maintainership. There, you can use adherence to arbitrary rules as a proxy measurement[1] for attention and effort on the part of the submitter. And that I have no problem with.
But the actual value of code formatters is IMHO extremely low in practice, and the cost isn't "high", but is non-trivial.
I get this a bit at my job, and I think there's a difference between making changes (which I do a lot of) and being confident in the changes that you're making. The environment I'm in is completely fault-intolerant, and we're currently hamstrung by our hardware (e.g. no backups/no secondaries/etc.) so changes that we're making have to be well-reasoned and argued before they're put in.
Some people take that as being scared, but it's more like "you have to have made this work and tested it before putting it in."
reply