> Conceptually continuous integration is generally integrating 2+ different lineages of code together
> In practice, CI [often means] "automated test server"
Could you say more? I use "CI" to refer to the automated processes that run tests and (maybe) deploy code as it is merged to some blessed branch. It's what continually integrates the new code into the existing code. What am I missing?
If there's 1 developer working on 1 branch at a time: main is at commit A, you branch add B and C, you merge now main is at A, B, C. Your "integration" was just moving the code forward and if you ran tests on A, B, C commits and it passed, the tests would still pass on main.
Now say there's 2 developers that branch off A. Dev 1 removed dead code coolUtil and with it deleted module coolLib and commits B1. Tests pass, code works. Dev 2 adds new coolUtil2 in commit B2. Tests pass, code works. Now they both merge their changes back to branch A so it's A, B1, B2 or A, B2, B1 or A, B3 (merge of B1/2). Anyway, you try to run the code and it fails. Everything merged clean but Dev 1 removed the lib Dev 2 depends on. They didn't create any file level conflicts because they edited different things so the merging went fine however now the code is broken.
The real integration part comes from reconciling different (potentially conflicting) changes and making sure the end result still works. The server is doing the integration automatically and verifying it automatically
You could skip the server and merge everything on your machine and run the tests on your machine and achieve the same result. Still CI, no server, no automation
I think it's fairly known among "LLM practitioners" (or what to call it), that some languages are better at solving specific tasks. Generally if you find yourself in a domain dominated by research in language X, shifting your prompts to that language will give you better results.
I suspect that each player has a bowl of stones, and they have 1 lid that covers those bowls. After taking a turn, the player puts the lid over their own bowl so that the other player can easily see that its their turn.
"Drive by" game, to me, sounds like they've got the board set up somewhere in the house, and make moves over the course of a day (days?), rather than sitting across from each other and having dedicated time for the game.
> Next.js tightly couples your front-end and back-end, no question.
I'd question that statement, since it's wrong. There's no requirement to connect your NextJS server to your backend databases, you can have it only interact with your internal APIs which are the "real backends". You can have your NextJS server in a monorepo alongside your APIs which are standalone projects, and Next could exist solely to perform optimized payloads or to perform render caching (being the head of a headless CMS). It seems like a weird choice to make but you could also build almost a pure SPA have have Next only serve client components. The tightness of the coupling is entirely up to the implementor.
I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases.
Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.
This is an hour long survey of the accumulated wisdom of a software developer who clearly cares a lot about the craft.
I listened to it this morning while doing my stoutness exercises, and there's a lot of good wisdom here. I'll probably chase down some of the books he mentions. If you're not concerned with the philosophical preamble, skip to the 5:15 mark.
Thanks! The books and essays are fantastic, and if I get a few people to read them, this will have been a successful talk!
Re: LinkedIn—Ha! I debated on how much to include/not-include specific references to my previous employer there, and erred on the side of “let’s keep this grounded in specific real-world experience at least a little”. I think you might get mildly tipsy, but not terribly drunk.
At some point, you just have to close the window. I can only realistically do 10/25 résumé per day and still do my job.
All most all hiring has a strong element of luck. I've hired really good engineers that can't write a resume or aren't self promoting enough in an interview and they seem kinda flat. But they roll in and make good decisions, good products, good documentation and they are easy to work with.
If I could, I'd talk to everyone on the phone for a few minutes to get a feel but I can't do that either.
Of course, and that right there is luck of the draw. Didn't list the specific thing I need help with? Might not make it to the list of 20 I look at. Not because I wouldn't hire someone for not listing it, or demonstrating they can Lear quickly but jiet be cause I have a limited amount of time.
Or it's look at schools. See if any of the companies pop out and they spent some time there. Obvious exact skills match. The resume isn't too long. Whatever I can get in a 30 second skim.
> In practice, CI [often means] "automated test server"
Could you say more? I use "CI" to refer to the automated processes that run tests and (maybe) deploy code as it is merged to some blessed branch. It's what continually integrates the new code into the existing code. What am I missing?