Doc Avid Mornington

Pretty sure they meant to not have review. Dropping peer review in favor of pair programming is a trendy idea these days. Heh, you might call it “pairs over peers”. I don’t agree with it, though. Pair programming is great, but two people, heads together, can easily get on a wavelength and miss the same things. It’s always valuable to have people who have never seen the new changes take a look. Also, peer review helps keep the whole team up to date on their knowledge of the code base, a seriously underrated benefit. But I will concede that trading peer review for pair programming is less wrong than giving up version control. Still wrong, but a lot less wrong.

Or gets promoted, and keeps moving on to new and bigger projects, leaving a trail of destruction, because all management sees is they close tickets faster than the people who are busy picking up the pieces behind them.

Emacs Magit is so much better than the CLI, and I don’t say that lightly. And it’s available on Linux.

I barely know Vim, I’m an Emacs guy. Every time I pair with a colleague using an IDE, I find myself having to exercise great restraint, and not complain about how slow and fussy everything they do is. When I’ve worked with skilled vimmers, I have to admit that they invoke the deep magic nearly as efficiently as I do. Hotkeys? Pshaw, child’s play.

Saying that some projects, at some point in their lifecycle, don’t need certain things, is not saying that those things have no place. Also, if one can’t design a monolith that isn’t bloated and tightly coupled, one definitely has no business designing microservices. Using microservices is neither necessary, nor sufficient to achieve decoupling.

Monolithic services are the ideal way to begin a project, as using basic good practices, we can build a service that does many things with minimal coordination, and as it grows and requirements change or are discovered, we can easily refactor to keep things simple. As the software matures, we find the natural service boundaries, and find that certain pieces would perform better if they were separated out and could scale independently, or act asynchronously. Since we have followed good practices, this should usually be a simple matter of removing a class or module to a new service, and replacing it with a facade, such that the rest of the monolith doesn’t have to change at all.

I do rather like science.

I think Vim is more popular with sysadmins because, historically, you could count on Vi or Vim being available on just about any server you had to do some work on, while Emacs might not be. That’s still probably somewhat true, although in the world of clouds, containers, and source-controlled, reproducible configuration, it’s probably less common to edit files in place on a server.

However, with Emacs tramp, you can edit files just about anywhere you can access, by any means, even if there is no editor installed there at all, using your local Emacs, with all your accustomed configuration. Like popping open a file inside a container running on a remote server by ssh, something I’ve done a lot of lately, debugging services running on AWS ECS.

Just use a single instance of Emacs to edit everything everywhere all at once. You can even use vim keybindings if you have no taste.

Fucking apeshit craze-balls, makes sense, business as usual.

Medication helps a lot of people, and CBT is very effective for others. I’ve never heard of a “technique” that’s effective against depression that can be reasonably described like that, but I’m not an expert. Would love some concrete examples.

Programming is the art of juggling of state and control flow

Sure, stateless functions deal with and impact state in some way. If that’s what you meant by your previous comment, that’s fine, but that’s honestly not what would typically be meant by “juggling” state.

The part about declarative languages has nothing to do with state. Declarative languages do not give the programmer control over flow, the other part of your definition.

Learn Lisp, and you will never again be so certain about the difference between a programming language and a data format.

No, my question does not imply a pure functional language at all. Pure functions exist in languages which are not purely functional. Most of the functions I write are pure functions. I could have a workflow where I work with another programmer who handles the minimal stateful pieces, and I would only write stateless functions - would that make me not a programmer?

(There are also purely functional languages, by the way. I just didn’t remotely imply there were, or make any claims about them, at any point in this thread, prior to this parenthetical.)

The part about declarative languages has nothing to do with state, or functional languages. Declarative languages are a whole different thing. Of course declarative languages handle state. The comment I was replying to said “Programming is the art of juggling of state and control flow”. Declarative languages don’t involve juggling control flow.

I didn’t say there is…

No, it’s really not.

So, writing stateless functions, or working in declarative languages doesn’t count?

Oh yeah, and anybody else who had fetched in those commits may still have them as well. It’s hard for something to be gone-gone, but it may be annoyingly-hard-to-recover-gone.

Orphaned commits can get garbage collected at some point, though.

You only named one upside, I can’t think of any other, and C-like syntax is pretty common, so it’s not much of an upside. It’s at least debatable whether the JVM is a good thing at all - the majority of languages get along perfectly well without it, and there’s no reason to believe the ones that do target it wouldn’t be doing just fine if it didn’t exist. It’s weird to say Java gave a job to anybody - the demand to have software written resulted in programmers being hired; if Java hadn’t been pushed on the market by Sun, it would have just been another language. Java didn’t establish any fundamentals at all, it just borrowed from other places. While all three of the other languages you mention are interesting, for sure, I’m not sure why somebody who doesn’t like Java should limit themselves to JVM languages.

I get the feeling you feel like I was somehow calling you out. I want to clarify the the intent of my message was more in the spirit of “wow must be nice” than “you’re making that up”. But also I’m just interested in how different your experience is from mine.

Who said anything about only requiring 1 reviewer?

I must have misunderstood. You said “If no one has reviewed your change within 24 hours you are allowed to approve it yourself.” To me, that sounds like, after 24 hours of no review, one self-approval is considered sufficient. That, in turn, seems to imply that before 24 hours, one non-self-approval is probably sufficient, no?

You should try working for a healthy team where everyone takes collective responsibility and where the teams progress is more important than any one person’s progress.

I’ve had team members in the past who are very self-focused, they tend to close a lot of tickets and look good, then get promoted out, leaving an unmaintainable mess behind. Allowing that is generally a failure of leadership. But right now, that’s not our problem, and what you describe is pretty much how we operate.

I’d love to work on a team where everybody took code review a lot more seriously, believe me, it’d be nice, but my team does generally get everything approved, with at least two non-self approvals, in under 24 hours. If something is getting ignored because people are busy and it’s a large change because we aren’t perfect, and there is some reason to get it in soon, it just takes a quick request on Slack to get the needed attention.

What I found surprising about your description was more that the potential of a self-approval coming up would, in itself, get people’s attention, rather than somebody reaching out personally and asking for a review.

Our big weakness is review quality, not quantity. It’s crazy the number of times I look at something and see the two or three approvals already, start going through it, and find issue after issue. I see that on other teams as well, where there’s usually only one or two devs who ever really make any comments on a review, it seems to be very common.