See, you’re not claiming that processes are important, you’re claiming that your process is important and

No, I’m claiming that processes are important.

It’s important that stumbling upon a tangentially related bug or even linting issue does not block your work, forces you to fork your work, nor forces you to work around it. It’s important that you can just post a small commit, continue with your work, and only handle that in the very end.

It’s also important that you can work on your feature branch as you please, iterate on tests and fixes as you see fit, and leave cleanup commits to the very end so that your PR contributes a clean commit history instead of reflecting your iterations.

It’s important that you can do any work you feel is important without having to constrain yourself to adapt your work to what you absolutely have to push your changes in a squraky clean state without iterations.

It’s important that you can work on tasks as well as cleanup commits, and not be forced to push them all in a single PR because you are incapable of editing your local commit history.

It’s not about my workflow. It’s about the happy path of a very mundane experience as a professional software developer, specially in a team which relies on a repository’s commit history to audit changes and pinpoint regressions.

This is stuff anyone who works in professional teams can tell you right away. Yet, you talk about this if it was a completely alien concept to you. Why is that? Is everyone around you wrong and your limited superficial experience dictates the norm?

Yet you talk about autism.

Oh, okay. I’ve never encountered a situation where I needed that bug fixed for the task but it shouldn’t be fixed as part of the task;

So you never stumbled upon bugs while doing work. That’s ok, but others do. Those who stumble upon bugs see the value of being able to sort out local commits with little to no effort.

Also, some teams do care about building their work on atomic commits, because they understand the problems caused by mixing up unrelated work on the same PR, specially when auditing changes to track where a regression was introduced. You might feel it’s ok to post a PR that does multiple things like bumping up a package version, linting unrelated code, fixing an issue, and post comments on an unrelated package, but others know those are four separate PRs and should be pushed as four separate PRs.

if they’re touching the same functionality like that I really don’t see the need for two PRs.

That’s ok, not everyone works with QA teams. Once you grow over a scale where you have people whose job is to ensure a bug is fixed following specific end to end tests and detect where a regression was introduced, you’ll understand the value of having tests that verify if a bug is fixed, and only afterwards proceed with changing the user-facing behavior. For those with free-for-all commits where “fixes bug” and “update” show up multiple times in their commit history, paying attention to how a commit history is put together is hardly a concern.

And those who don’t immediately insult

Pointing out someone’s claim that they don’t care about processes when it’s the critical aspect of any professional work is hardly what I’d call an insult.

Just go ahead and say you don’t use a tool and thus you don’t feel the need to learn it. Claiming that a tool’s basic functionality is “a solution in search for a problem” is as good as announcing your obliviousness,and that you’re discussing stuff you hardly know anything about.

That sounds like a solution in desperate need for a problem.

It’s ok if you never did any professional software development work. Those who do have to go through these workflows on a daily basis. Some people don’t even understand why version control systems are used or useful, and that is perfectly ok. Those who do work have to understand how to use their tools, and those who don’t can go about their life without even bothering with this stuff.

See, I don’t think you understood the example. The commits built upon each other (bugs are fixed while you work on the task, and to work on your task you need the bugs to be fixed) and reordering commits not only take no time at al but they are also the very last thing you do and you have to do the just once.

It’s ok if you don’t feel a need to change your persona workflow.

Nevertheless I’m not sure you understood the example, so I’m not sure you fully grasp the differences.

The whole point of my example was to point out the fact that, thanks to interactive rebase, you do not even need to switch branches to work on multiple unrelated PRs. You can just keep going by doing small commits to your local feature branch and keep doing what you’re doing. In the end all you need to do is simply reorder, squash, and even drop commits to put together multiple PRs from commits that are built upon each other.

Simple, and straight to the point.

If you need anything more complex than cherrypick, you already screwed up big time.

I think this is a clueless comment. You can use Git to greatly improve your development workflow if you dare going beyond the naive pull/commit/push workflow.

Take for example interactive rebase. It let’s you do very powerful stuff such as changing the order of commits in a local branch and merge/squash contiguous commits. This unlocks workflows such as peeling off bugfix and cleanup commits from your local feature branch without having to switch branches. I’m talking about doing something like:

a) - you’re working on your task, b) - you notice a bug that needs fixing, c) - you fix the bug and commit your fix, e) - you continue to work on your task, f) - you notice a typo in your bugfix code, so you post a fixup commit. g) - you post a few commits to finish your task, h) - you noticed your bugfix commit didn’t had the right formatting, so you post a couple of commits to lint your code both in your bugfix commits and task.

When you feel you’re done, you use interactive rebase to put everything together.

a) you reorder your commits to move your bugfix commit to the top of your local branch, followed by the typo fixup commit and the linter commit. b) you mark both the typo and linter commits as fixup commits to merge them with the bugfix one, c) you post a PR with the single bugfix commit, d) you finally post a PR for your task.

Notice that thanks go git interactive rebase you did not had to break out of your workflow or do any sort of context switch to push multiple PRs. You just worked on things you had to work, and in the end you just reorganize the commit history in your local branch to push your work.

Is this what you call “screwed up big time”?

I think it’s hard to provide examples of a binary format beyond a few benchmarks.

Was this thing generated by a poorly trained LLM?

Walter Bright has fairly odious political opinions;

I fail to see the relevance of what personal opinions and beliefs he may or may not have. You’re making it sound like the goal is not to improve a language ir fix issues, but to take something away from a person just because you disagree with their political opinions. That’s hardly good use of anyone’s time, and sounds terribly petty behavior.

I wish I had that much free time to be able to waste it being so vindictive about such trifling issues.

Which languages have you invested/migrated to, only to find that “political stunts” had a “negative impact” on your planned development?

I don’t waste my time with meaningless irrelevant stuff. Either a tech stack serves it’s purpose, or it doesn’t. I don’t have enough free time to waste it trying to cancel others.

From the blog post, it sounds like the underlying motivation is not tied to technical aspects but control over the language. If I had invested any of my personal time onboarding onto D and migrated any of my projects to D, I would be concerned about the negative impact these political stunts have on the tech stack.

Perhaps I’m being dense and coffee hasn’t kicked in yet, but I fail to see where is this new computing paradigm that’s mentioned in the title.

From their inception, computers have been used to plug in sensors, collect their values, and use them to compute stuff and things. For decades each and every single consumer-grade laptop has adaptive active cooling, which means spinning fans and throttling down CPUs when sensors report values over a threshold. One of the most basic aspects of programming is checking if a memory allocation was successful, and otherwise handle an out-of-memory scenario. Updating app states when network connections go up or down is also a very basic feature. Concepts like retries, jitter, exponential back off have become basic features provided by dedicated modules. From the start Docker provided support for health checks, which is basically am endpoint designed to be probed periodically. There are also canary tests to check if services are reachable and usable.

These exist for decades. This stuff has been done in production software since the 90s.

Where’s the novelty?

Having said this, I’d say that OFFSET+LIMIT should never be used, not because of performance concerns, but because it is fundamentally broken.

If you have rows being posted frequently into a table and you try to go through them with OFFSET+LIMIT pagination, the output from a pagination will not correspond to the table’s contents. Fo each row that is appended to the table, your next pagination will include a repeated element from the tail of the previous pagination request.

Things get even messier once you try to page back your history, as now both the tip and the tail of each page will be messed up.

Cursor+based navigation ensures these conflicts do not happen, and also has the nice trait of being easily cacheable.

For the article-impaired,

Using OFFSET+LIMIT for pagination forces a full table scan, which in large databases is expensive.

The alternative proposed is a cursor+based navigation, which is ID+LIMIT and requires ID to be an orderable type with monotonically increasing value.

You don’t need any of it, relevant experience is worth in the region of 5x-10x for every hiring manager I’ve known, and for myself.

The only time I had to brush up on data structures and algorithms is when I apply to job ads, and recruiters put up bullshit ladder-pulling trivia questions to pass to the next stage of a recruiting process. It’s astonishing how the usefulness of a whole body of knowledge is to feed gatekeepers with trivia questions.

"Appendable” seems like a positive spin on the (…)

I don’t think your take makes sense. It’s a write-only data structure which supports incremental changes. By design it tracks state and versioning. You can squash it if you’d like but others might see value in it.

I’d love to see benchmarks testing the two, and out of curiosity also including compressed JSON docs to take into account the impact of payload volume.

Nevertheless, I think there are two major features that differentiate protobuff and fleece, which are:

• fleece is implemented as an appendable data structure, which might open the door to some usages,
• protobuf supports more data types than the ones supported by JSON, which may be a good or bad thing depending on the perspective.

In the end, if the world survived with XML for so long, I’d guess we can live with minor gains just as easily.

We have a client which is MAD cause the project is riddled with bugs, but the solution somehow is paying more attention. Except that it clearly isn’t feasible to pay more attention when you have to check, recheck and check again the same thing over and over…

By definition, automated testing means paying more attention, and doing it so well that the process is automated.

They say it’s a waste cause you can’t catch UI (…)

Show them a working test that’s catching UI bugs. It’s hard to argue against facts.

but they somehow think they are smarter than google or any other small or big company that do write test

Don’t sell a solution because others are doing it. Sell a solution because it’s a solution to the problem they are experiencing, and it’s in their best interests to solve it. Appeals to authority don’t work on everyone.

I understand. I have to admit I felt a little dirty after pasting that text.

(…) it was "because the organizer wants big names and it probably seemed like an easy way to address their diversity concerns.

Wouldn’t it be easier to, say, invite real people to deliver real talks? How exactly is it easier to spend multiple years maintaining sock puppet accounts than simply sporadically extend an invitation to someone?

Eduards Sizovs, the DevTernity organizer accused of making up fake female speakers, felt it was the right PR move to post this message on Twitter:

https://twitter.com/eduardsi/status/1728447955122921745

So I’ve been called out (and canceled?) by listing a person on my conference’s website (who never actually made it to the final program). JUST A RANDOM PERSON ON THE CONFERENCE WEBSITE canceled all the good work I’ve been doing for 15+ years. All focus on that.

I said it was a mistake, a bug that turned out to be a feature. I even fixed that on my website! We’re cool? Nooooo, we want blood! Let’s cancel this SINNER!

The amount of hate and lynching I keep receiving is as if I would have scammed or killed someone. But I won’t defend myself because I don’t feel guilty. I did nothing terrible that I need to apologize for. The conference has always delivered on its promise. It’s an awesome, inclusive, event. And yes, I like Uncle Bob’s talks. They’re damn good.

When the mob comes for you, you’re alone. So, let it be. I’ll keep doing a great conference. With all speakers, half the speakers, or I’ll be speaking alone on all tracks and lose my voice. But the event will be a blast. Like always. I’ll die while doing great work. But the mob won’t kill me.

I don’t think that tone-deaf is the right word for this.

From the article:

“To spell it out why this conference generated fake women speakers,” Orosz alleges, it was “because the organizer wants big names and it probably seemed like an easy way to address their diversity concerns. Incredibly lazy.”

How hard is it for these organizers to actually reach out to women developers and extend an invite to talk about any topic they are interested in? In the very least, there are tons of high-profile bloggers who are vocal about things and stuff. Even though women are severely outnumbered, you almost need to go way out of your way to avoid actually extending an invite to a woman in the field.

You used the wrong search bar, you just used the one for the file list.

The fact that one of the excuses for GitHub search results being subpar is that there is a right and a wrong search bar is already telling.

must have been a half ass attempt

How hard do you need to try to use a feature for it to be considered decent? Do you expect something as basic as a search to put up a fight?

The biggest news to me is that GitHub allows users to search code. Every single time I tried to search something in GitHub, search results were next to completely useless, and always a sure-fire waste of time and effort.

There’s hope, I guess.

They used it because it was an established term

My graph theory is a bit fuzzy but I think that the definition of a branch in a directed graph corresponds to the path between two nodes/vertices. This means that by definition any path from the root node to any vertex is itself a branch.

I don’t think Git invented this concept, nor did any other version control system.

I know that “branch” helps intuitively and visually when it’s actually an offshoot with one root and a dangling tip, like an actual tree branch…

I think that your personal definition of a branch doesn’t correspond to what graph theory calls a branch. Anyone please correct me if I’m wrong.

If a library or framework requires boilerplate code it’s a bad library or a bad framework.

I think this take is uneducated and can only come from a place of inexperience. There’s plenty of usecases that naturally lead to boilerplate code, such as initialization/termination, setting up/tearing down, configuration, etc. This is not a code smell, it’s just the natural reflection of having to integrate third-party code into your projects.

From the article:

By library, I mean any software that can be run by the user: shared objects, modules, servers, command line utilities, and others. By service, I mean any software which the user can’t run on their own; anything which depends (usually through an API) on a service provider for its functionality.

It looks like the blogger took a page out of Humpty Dumpty’s playbook and tried to repurpose familiar keywords that refer to widely established concepts by assigning them entirely different meanings that are used by no one except the author. I’d also go as far as stating these redefinitions make no sense at all.

Perhaps the blogger might even have a point to make, but stumbling upon these semantics screwups is a major turndown, and in my case led me to just stop reading the blog post on the spot.

See also the C4 process RFC

What an unfortunate name.

https://c4model.com/

I was thinking of cross posting this to a Fortran community, but it looks like we don’t yet have one.

I’m sure everyone is still in comp.lang.fortran telling all kids to get off their lawns.

(…) there’s really nothing here for any competent programmer, even a fresh graduate. It turns out they they update the software by sending the update by radio.

How they send the payload is hardly the hard part of applying a software update. The hard part is stuff that you need to do after you have the payload: ensure the payload is valid, have the infrastructure in place to roll it out without bricking the hardware, be able to roll back faulty changes if some problem occurs after rolling stuff out, etc.

I can tell you with absolute certainty that this stuff is challenging for the majority of competent programmers out there, and they have the luxury of falling back to telling users to reboot or reinstall the app.

Taking UK as an example, you can call yourself civil engineer all day long without having to worry any legal consequences because there simply is no such thing as a licensing system for engineers.

Britain’s Engineering Council disagrees.

https://www.engc.org.uk/international-activity/access-to-practise-in-the-uk/

That is the work of a software engineer.

To build upon this, we need to keep in mind that at least in some jurisdictions the role of a certified engineer is only required in projects with relevant size, and the responsibility of that engineer is to ensure the project complies with all requirements and therefore be held responsible for any mishap. This means that it’s perfectly fine if non-engineers work independently on complex tasks, provided that an engineer attests that their output is fine and takes responsibility in case it isn’t and it causes problems.

This really depends on the country you live in.

Not really. There are two aspects to this problem: one is how people assign arbitrary and meaningless titles to themselves, and another is regulatory requirements by jurisdictions to be able to legally assume a role.

I can call myself senior dubstep engineer, and that’s perfectly fine. I can’t call myself a civil engineer and sign off on a construction project or a permit. No one cares if I’m actually a senior dubstep engineer or if I’m junior at best. In the meantime, you will get in trouble if you try to sign off on a construction project, no matter of how stubborn you are with regards to calling yourself an engineer.

As a former civil engineer who now works in software, “software engineer” irks me. “Engineer” means you’re supposed to be licensed and you have a responsibility for the public good above your responsibility to your employer.

This. I think some people don’t understand that titles are not whimsical status symbols and hold actual legal and regulatory meaning. A random guy can hold an engineering degree and not be an engineer, while a random guy with no degree can actually be a engineer if he jumps through all the hoops.

In engineering fields, being a member of a professional engineering body is critical to work in the field, because the main value proposition of these credentials is to prevent incompetent people from working on critical tasks which can potentially have important consequences to society if they are done poorly. For example, people can die if an engineer signs off on a project for a residential building that collapses due to shoddy work. If that happens then the engineers who signed off on the project will be investigated and if they are held responsible not only can they be held criminally responsible for their work but their license will be pulled, which is society’s response to ensure this problem won’t happen again.

Poorly defined nomenclature. Simple as that. I’m an “automation engineer”, have had many other titles (…)

Anyone can call themselves what they feel like it. However, in some jurisdictions and contexts the title “engineer” does have a specific meaning, consisting of someone who not only has the necessary and sufficient training but also is a member of a specific professional body. These credentials have meaning and those who try to pass themselves off as one without having the certification or credentials might be breaking laws.

Non profit doesn’t mean they earn nothing

You need a valid business model to keep an organization ticking. Staff doesn’t live out of hopes and dreams. It’s hard enough to get a for-profit software company to stay up. If your starting point is that the company is not focused on getting a profit then it all sounds as hopes and dreams instead of an actual business plan.

I’m not sold on user replaceable phone batteries, but USB-C was a long time coming.

As someone who had a perfectly fine Android smartphone die because its battery went dead, and had to replace it with an off-brand one to keep it ticking… I can assure you that the lack of support for user-replaceable phone batteries is forcing people to throw away perfectly good hardware.

There are parallels to be drawn between licensed professionals (like doctors, CPAs, lawyers, civil engineers) that they all have time under a professional and the professional then signs off and bears some responsibility vouching for a trainee.

We need to keep in mind that the main value proposition of these licenses is to bar people from practicing. There is no other purpose.

In some activities this gatekeeping mechanismo is well justified: a doctor who kills people out of incompetence should be prevented from practicing, and so do accountants who embezzle and civil engineers who get people killed by designing and building subpar things.

Your average software developers doesn’t handle stuff that gets people killed. Society gains nothing by preventing a software developer from implementing a button in a social network webapp.

As a counter balance to that though, interviewers need to understand what they are hiring for and tailor the questions asked to those requirements.

This does not happen. At all.

Back in reality we have recruiters who can’t even spell the name of the teck stacks they are hiring for as a precondition, and asking for impossible qualifications such as years of experience in tech stacks that were released only a few months ago.

From my personal experience, cultural fit and prior experience are far more critical hiring factors, and experience in tech stacks are only relevant in terms of dictating how fast someone can onboard onto a project.

Furthermore, engineering is all about solving problems that you never met before. Experience is important, but you don’t assess that with leetcode or trivia questions.