Atomic Git ONLY WAY TO USE GIT | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord

[@defnlife1683]

“Atomic does one thing and only one thing that can be summed up in 1 sentence.” “Refactored codebase.” 50k line change.

[@jacoboblanco1555]

Yeah I was gonna say “migrate from JavaScript to C++”

[@defnlife1683]

"Drank redbull and swapped all normie math with bitwise operations."

[@earthling_parth]

Hahahaha

[@bluecup25]

I have a colleague whose commit message on every single commit ever is "I fixed it."

[@ripplecutter233]

literally me

[@julkiewicz]

The productivity gain is that you can do atomic commits all over the place and then revert all leading to twice as many commits to your name. That'll get you a promotion

[@ThePrimeTimeagen]

BOOM

[@CottidaeSEA]

Sounds like a previous colleague of mine. Did everything hastily, looked really good in the statistics, then the rest of us had to clean up his messes which made our statistics look bad. Good times.

[@Mischu708]

My colleagues set the unit tests to pass manually so it shows 100% coverage. This week one colleague did a change and broke 2 modules but all the tests passed.

[@sck3570]

@@Mischu708 give that guy a medal

[@davixx1995]

Made me think of my previous team leader, he captained a project which under his direction ended up being a nightmare from day 1, but the details are another story, what appalled me the most was when he started actually coding himself, usually wouldn't be the case but we needed to fix stuff fast, and he put in tons of micro commits that were just commenting a bunch of lines only to decomment them in the next commit, or deleting and re adding lines, or just straight up putting in regressions. At that point I was just thinking he was a mediocre leader and kinda shitty person, but that was when I realized his actions were straight up malicious. He left the job halfway through to work full time for his startup, though i seriously doubt the decision was that one-sided.

[@samuelfaure4332]

Just discovered this video about this article I wrote. Love the feedback, it's harsh but fair, exactly as it should be in our industry. Glad you liked some parts of it. By the way I also loved the videos where you disclosed your ADHD, as a developer with the same condition I'm grateful for the representation. Cheers.

[@johnnycochicken]

wholesome

[@alichamas63]

Makes me just want to...wait, what was I doing?

[@LewisRidyard]

It was really refreshing hearing you talk about how you approach a piece of work. That initial exploratory coding phase, followed by a more focussed pass, isn't talked about enough. Honestly I think it would be great topic for a separate video.

[@robmorgan1214]

Bingo. It's just like anything else. Like writing an important book or article. Get organized and orient yourself properly on the problem. Play with your solution, make a solid design plan, and build towards solving the final problem or tackling the final boss a piece at a time... if you do things this way, you can even include others breaking off small tiny bits and farm them out to junior programmers... I once even drafted in-house council to write a complete protocol after spending 10 min teaching him the necessary language features and explaining him the spec (normally this would have been unnecessary but we were behind and shorthanded). Turns out the LSAT is approximately 100% logic and language games, which means his protocol actually shipped on time with zero bugs! ... he hated it and avoided me for a little while after that, but he got the job done. Lol!

[@anj000]

I really liked this take. I've heard couple times about incremental refactoring, but in his rant he really nicely described it in simple, descriptive language. And for one time I felt that I'm not that bad if I'm unable to plan everything ahead and write it perfect from the start, and that it is actually normal.

[@headlights-go-up]

I don't get to catch your streams often, so you taking the time to put these chats up on YT is greatly appreciated. Ty, friend

[@issy_dev]

We use squash merge at work. PRs are generally encouraged to be small - anything that can be merged independently of the rest of the PR can be put in a separate PR. This results in what you might call atomic commits on the main branch, but it doesn’t over prescribe a workflow for the individual developers when working locally.

[@dealloc]

We do the same. I long for built-in UI as part of GitHub and GitLab to do this. Being able to select commits to create a new PR from then, rebase the original PR to omit those from it. Any conflicts should be handled manually, of course, just like merge conflicts.

[@astronemir]

We use Gerrit, but I find it really annoying to use. I already did atomic commits and commit based review..

[@dealloc]

@@Ultr4noob Do you mean you only create 1 commit per PR? Because that would be bad and not what squashing is.

[@dealloc]

@@Ultr4noob Depends on the size of that commit. If one commit does more than a single common thing as part of a larger changeset it harder for _you_ to maintain your own branch and harder for others to review individual commits.

[@Patrk38]

@@dealloc that’s why PRs are supposed to be doing just one thing

[@williamlvea]

All these people coming up with fancy ways to use git, but they all forget the most important step: git gud

[@omgCHopper]

I revert sometimes. Atomic commits are great when you use git blame to understand why someone wrote a line or block of code a certain way

[@ThePrimeTimeagen]

yes, i love atomic commits and do try to follow them as much as possible, but its never a guarantee that it can be done :)

[@ruukinen]

@@ThePrimeTimeagen Yeah sometimes you gotta keep the flow going when you have that vision in your head. I sometimes think I commit too frequently but reviewing your changes in github somehow just makes me notice problems better than diffing them in console or looking at the code in the IDE.

[@sarethdarva]

I didn’t know there was a name for this approach-it’s what I’ve been doing for a while. For me it was motivated by ease of review and meaningful feedback, because naturally long PRs just aren’t going to be reviewed in a timely and thorough way. To me that alone makes atomic git worth it.

[@mattymerr701]

"It should be summarised in a simple sentence" is a bad yard stick. "Implemented x feature" is a simple summary, "moved a function" is another. Wildly different scopes.

[@betterinbooks]

I think if you did an introduction to git tutorial it would be helpful to many new engineers.

[@arrux4822]

Fireship already made the best one imho

[@betterinbooks]

@@arrux4822 but fireship uses -puke- vs -puke more- code. and I don't mean a video that just talks about commands but where to use them and how often and why. best practices etc. I don't think fireship has a video like that.

[@lpanebr]

I like the concept of the atomicity being tied to the short one sentence explanation, independently of the code change!

[@boody8844]

Doing smaller commits is def a good habit to learn. Since sometimes I find myself doing git commit -m "added some things" which is not ideal at all lol

[@darthmoomoo]

I make completely random commits on feature branches. Possibly trying to keep commits limited to one or two logical compile units. And then I rebase interactive and squash/rearrange commits to make it easier to bring in upstream changes before merging into master. This ends up with clean history on the master branch as well. This leaves me free to fck around on the feature branch while the master branch remains clean/linear.

[@dealloc]

I do the same, but there are cases where you end up cross-pollinating changes resulting in larger commits of unrelated changes that could be made smaller and more focused. In such cases, I rebase to edit the commit, then use git add -p to select the changes that makes sense together.

[@darthmoomoo]

@@dealloc Yup. I also split up commits if they end up with unrelated files. "git reset HEAD^" and "git add -p" are the tools for the job.

[@oliverfunk]

I don't see why commits should matter unless ur working with other people on a feature branch. We sqush-merge PR's into dev so the commit message is sematic, descriptive and the PR can be found for more context etc. So in that sense they are atomic but the commits in each PR aren't.

[@matthewkaras7722]

I turn TDD on its head - how can I write code before I think about its intended behavior at that point in development? TDD is just writing down that ephemeral behavior before writing down the code that implements that behavior. It's just note taking. I can totally write - "at this point in time - I think the function should return the sum of two integers - if I were to use it - this is how it would behave". That's all. What's good about it is that you focus on the ergonomics of the code first - rather than the implementation of that code. It also pins down the level of abstraction of the inputs, because you're not forced to conform to the unimplemented code's requirements.

[@CottidaeSEA]

I think it sort of makes sense when you're doing stuff like converting your own internal objects to something you can send to an external API. However, the API will tell you if things are correct or not, and assuming you have test credentials all is good. After that you write a test to ensure nobody unintentionally messes things up later on. TDD can work if you already have a set interface you have to work with, but that's about it.

[@dtkedtyjrtyj]

@@CottidaeSEA No! It's _not_ about the tests. TDD is so misunderstood that they renamed it to BDD, which is just TDD but with the hope that people wouldn't think it was about the tests. TDD is about _design_ , specifically how you design the api of your code. The testing is just a side effect, nice one sometimes, but not the main point. Maybe TDD isn't the perfect solution for everything; but every time someone complains about it they say something that makes it clear they _don't_ understand the point. Like "After that you write a test to ensure nobody unintentionally messes things up later on." NO! You write the test to ensure that the code you are writing _now_ does what you intend for it to do and does so in a way that is _easy_ to use.

[@CottidaeSEA]

@@dtkedtyjrtyj What I described wasn't TDD. What I described was reality.

[@CottidaeSEA]

@@dtkedtyjrtyj Also, tests first is like trying to predict the future and you more often than not end up having to adjust the API because you missed something.

[@darylphuah]

this is pretty much spot on.

[@tonywtyt]

I can't remember the last time I reverted! Also, if I'm working on something that complicated, I wouldn't be pushing the commit. I would realize my own lack of certainty about an approach. If I was totally screwed locally, I'd kill my branch and start fresh with my new found perspective. When I have had to do this, I've always been able to redo the good parts quickly.

[@mskiptr]

git send-email lol You write your changes committing when you need, re-arrange it a couple times until the patch series is clean and easy to review and finally you send it to the mailing list. The maintainer does git am and it lands upstream.

[@nicholaswillhite5888]

IMO, TDD shines for bug fixes, not feature implementation. There's a logical leap needed in TDD for feature implementation; you already know how to implement the feature. Until you've implemented a lot of features, or the same feature several times, the "unknown unknowns" you'd want a test for can't be determined. In the "I've never done this" or "how would/should this work" mindset, a TDD approach only results in tests that amount to a tautology.

[@martinmusli3044]

If you know how to implement it, you know how to write an interface through which to test it. Don't see the problem here

[@jadencorr6897]

TDD is also useful for cases, when exact specification is predefined and May also be complicated. For example, merging of several objects in the database, etc. You know what you should get even before you state to wrire anything. But it's not that often you have exact specified result and approach to wrire test before understanding of interfaces.

[@timtjtim]

@@martinmusli3044do you know the interface of what you’re writing before you write it every time? You never start writing code and realise it’s wrong?

[@martinmusli3044]

@@timtjtim No I don't. When I realise something is wrong, I make the code right. And since tests are code I make the test right ;)

[@DieterPrivate]

​@@timtjtim TDD isn't TFD, huge difference. The idea of Test Driven Design is that you do have tests before the design gets into production, it doesn't state they should be written first...

[@metaltyphoon]

The best productivity boom was learning `git add -p`, specially if you like to do everything at once.

[@ruukinen]

Doesn't your IDE allow you to add new files as you create them? I never add files during consoling due to that? Or at least I can't remember the last time I did.

[@kriscarr2442]

If you think TDD means you do all your design and tests up-front you don't know what TDD is. Most people are taught very wrong. You just use a test function instead of a main function and build it up as you go, it "drives" design and development. If you start with a main function instead to do your messing around you are going slower and wasting time. You may end up deleting half your tests but the remaining half is still there and coverage is pretty decent.

[@alexkozliayev9902]

Yes, you write test, you write code, you write test, you write code. It's literally how it's taught by the author of TDD

[@sk-sm9sh]

How do you know that I'm going slower? Don't you think I'd know better what works faster for me than you?

[@kriscarr2442]

@@sk-sm9sh ah sorry let me clarify, it's slower if you want tests, otherwise it's equal unless TDD actually ends up saving you time say if it helps identify an issue earlier or something but that's speculation. TDD should be "cost-free" from a time/effort perspective. There's no speed difference in doing TDD vs not doing TDD at all, that's one of the main promises. This is due to you simply using a "test" function instead of a "main" function while developing and running that instead, so there's no extra actual "work" involved. So you're going slower by not doing this simply through having to duplicate work "if" you ever want tests. This is due to you having to write those tests separately after-the-fact. If you never want any tests then you won't go any slower but you also won't have any tests you could have had for "free" so that's a bit of a waste. Any tests from TDD you don't want/need to keep should just be deleted once you're done. Think of them as little "temporary main functions" for messing about with having as many at once as you need as you try out different stuff. What "works for you" should be irrelevant as your actual approach or methodology or style for writing the code itself doesn't change, that's still 100% up to you and you should always do what works for you, just how you "drive" it changes. So not exactly sure what you mean by that but I wasn't saying how you develop code is wrong by any means, however you're doing it, TDD doesn't dictate that at all. Just that @ThePrimeagen 's definition and understanding of TDD is very wrong, leading to further spread of misinformation. What @ThePrimeagen is describing as "TDD" is indeed a horrible practice, totally impractical, unrealistic, and I totally agree should definitely be avoided like the plague, but it is not TDD. The idea with TDD is you figure out the design and shape (including any test cases) of the code/solution as you go, there's no requirement for anything up-front, whereas @ThePrimeagen seems to think you need everything already known and all tests/cases defined and written before you start development, which is madness. I like to think of TDD as "winging it with better visibility".

[@MrLowbob]

@@kriscarr2442 the main thing that i got taught for TDD was "wishful thinking" so okay "I want to do A, and the output of that should be X, so I write a Test for exactly that and then an empty method for it that currently should fail the test" and then "hmm... A consists of doing B and C, so I write a Test for B and C" and then create empty B and C and put it into my A functioni and then i can build things from parts that dont exist yet but what i expect them to do and test them all the way down, kind of writing the speciifcation first. its nice If you have a basic grasp of what to do , but its hard, when you don't know the problem domain well enough yet, imo.

[@nikhiljugdan724]

I think TDD is a skill, not a development pattern. TDD gives many benefits, to start with testing your code. That's gotta be the best because testing code as a developer is boring, specially for a case you have previously tested. With TDD automating that, it frees up mental space to develop what you have to. Any failures in previously working tests are caught automatically. That's sweet to say the least. Plus, it's an excellent way to document edge cases. But, Tests can be overdone. And I think that's what most people criticise about. It's something you learn by doing. Recognize your mistakes and improve on them. But yeah, tweeting about it is more fun.

[@bfitzger2]

Correct. If it's possible up front to see the right way to do something, then it's either an easy problem or something you've done multiple times before.

[@BenRangel]

I rarely have to revert commits: I roll forward. I do like a clean master history but to me that just means making small PRs and squashing them into master. I will keep each PR’s commit history because if I made a mistake: I can go back to that PR and follow my train of thought A PR history could be: 1. Render user.fullname in view 2. Add user.firstname and user.lastname to type 3. Render user.firstname in view 4. Style firstname 5. Remove uppercasing of firstname from view 6. Uppercase in css instead Maybe it’s a back and forth cause design changed their mind after I showed them a demo I want this squashed in master history. But available in the PR. If I find a bug, I just check the history for that PR and see if I messed up between 4 and 5

[@bonsairobo]

"Pretending you have the foreknowledge of the universe" Also known as "planning ahead"

[@LusidDreaming]

Just because a commit is atomic doesn't mean you can revert the commit without breaking everything that happened afterwards.

[@ivanmaglica264]

This is why I lately started to develop Feature Objects wherever possible. This way each feature is in it's own object with own context and changes can be more atomic.

[@arjavgarg5801]

Never thought of this

[@PavelPirogov]

Sometimes when you make very small change you can't commit it because it breaks some other thing and you need to cover these changes... and some more changes... and it's no more atomic commit.

[@canowyrms]

It sounds like he's describing agile. Break a problem up into smaller, more manageable chunks and bang em out.

[@gebob19]

these reacts are hilarious lmfao

[@ThePrimeTimeagen]

:)

[@endypendy18206]

I just saw ur vid on the dif channel forgot the name. forst time ive ever heard your “customer service” voice lmaoo primeagennnn

[@Leto2ndAtreides]

Hmm... As much as TDD has never spoken to me... His comment makes me wonder... If you do TDD in the style of achieving bite-sized progress: 1. Write small test 2. Make it pass 3. Repeat ... That might help in the face of too much complexity and related overwhelm ... It might be worth it to actually try using TDD again with that kind of approach in mind. Maybe after doing Kent C. Dodd's TDD course... Which I've bought but never gone through. lol I left it for whenever I started building my next startup - except that now there's too much excitement, and I don't feel like slowing that down by going into learning mode.

[@ThugLifeModafocah]

TDD is great, especially when you understands that it is not for tests.

[@Marco-dr2on]

Exactly, TDD maily helps with the design and architecture of the production code and also with understanding the problem at hand better

[@deanolium]

Though it mainly helps when the code you're writing the tests for is well defined. So given the inputs and context, you know what the output should be. It also helps with writing better tests since you don't know the implementation yet so you're less likely to be accidentally testing that.

[@u9vata]

When you did the poll I must point out that you did not separate those who do atomic commits from those who don't... because if you don't, then there is a bias towards not being able to revert at all - so they do not even think about revert even if it would be beneficial. There was a time when I was very atomicly committing - there was also a time when I did something more crazy: atomic commits but right into the master / live system while developing huge features or refactors... The latter is even more work but it makes you 1.) not hook in new code but maybe test it with unit test as you go (I think this is much better than tdd ways) 2.) sometimes you can hook it in and you will naturally aim for that: this makes for "easier going" changes in the whole system. That being said... sometimes you do not want easy changes and the real issue is that the core architecture is wrong for example. Then doing this too much might work against your main goal of fixing the real shape of things. Still in many cases its a good idea. I think the key part is "let it be smallest but COMPLETE". The latter has a key point!

[@sk-sm9sh]

"X should do one thing and only one thing only" - insert whatever you like into x function/commit/class/app/module/whatever - is the bs I used to say when didn't used to have any more productive arguments.

[@StephanHoyer]

People underestimate the power of blame, especially in conjunction with smth. like gitlens you can see why a loc is like it is by cursoring to it. And atomic commits make this methodology much more enjoyable because you have reasonable messages to work with. That is the reason number 1 for atomic commits.

[@MrCreeper20k]

Started new job. I am the only dev in the US and there are 13 offshore devs. Massive refactorings needed, and I have not been able to sell refactoring to the boss, so I'll try to real home in on the incremental refactor angle. This channel does inspire me to be a better dev though, I'm loving it so far!

[@MorningNapalm]

Be careful. "Necessary" re-factorings are often not necessary, but quite disruptive. Do re-factoring as you have time to get it right, and be sure to get agreement from others. A good re-factor should be an improvement not only for you.

[@Waitwhat469]

I like atomic commits plus conventional commits because it means my git log can be made into a change log for the managers.

[@Mikopet]

tbh if you have a "clean history" (whatever is that), and you really have good tests, or at least could add new tests easily... it makes git bisect a very powerful tool.

[@ShootingUtah]

TDD is insane! I've never understood how anyone does it? How do freaking build? I need to try things to think through what I want to do.

[@gryg666]

and at the end: squash before merge :D

[@Kfoo-dj4md]

7:51 I did this shit so many times that I can't possibly count, it's my lifestyle now

[@robmorgan1214]

I've never reverted anything. Not even once.

[@KarlOlofsson]

I find it very hard to even remember to commit at all. I usually do it every time I have completed a working significant change, but that can be a lot of code.

[@danvilela]

Yeah, I called it a “session”! Every session I commit, like 2-4h of work. When I feel I completed something, time to commit.. sometimes there are 2 or 3 features at once and to be honest I love working like this.

[@code-chronicles]

Are you using some device to bleep the f word? Sorry couldn’t watch the live stream as we live in different time zone but I love the videos

[@JustAnotherLight]

atomic commits + git bisect is really good in case of a sneaky bug

[@RuiLopesFR]

One simple sentence: "Share short messages with others" - boom! Twitter committed.

[@gJonii]

I wait for the moment about 6 months from now when prime uploads a video "tdd is the best thing ever, why didn't anyone ever tell me about it?!"

[@JoseCarlosVM]

Yeah my 20 file PR is atomic, I'm working under the "Fat Atom Hypothesis" here

[@DonAlcohol]

refactoring/reorganising : my style: ctrl+a, ctrl+/

[@Patrk38]

Oh God, you hate TDD too? Ok, I’m in love.

[@kartik4792]

We just don't care about commits this much. We only use commits to identify who did the changes & in which PR. The rest of the information can be found in PR desc or linked Jira(😢) task. So, we only focus on making code changes without worrying about maintaining a clean commit history.

[@MarcosVMSoares]

TDD is not just do test first. TDD with only unit test normally doesn't work, test need to be focus on behavior not in "unit functionality". You should think in what you have and what you want for it. TDD is great is the best practice you could have ^^

[@dealloc]

But TDD requires you to know how the interface should look. You'll need to name things upfront and know how those pieces fit together to create this behaviour. You're already designing the API before even knowing what the implementation is going to look like. You're more likely to create more work for yourself than had you just started out doing things to get your head around it. When you work on large code bases across teams, you'll understand that TDD only really works when 1) you know the entire project inside out and 2) you know (or control) the requirements at any point.

[@bransonS]

TDD just requires you to know the next piece of you want implemented. It asks you to write 1 test, then make it pass. (Then refactor) then move on to 1 more test. The only time I’ve written many tests at once following TDD is it I’m wanting to refactor someone’s old code, in which case your comment resonates more. I don’t think TDD is necessary all the time, but I also just did not agree with your comment about TDD in practice. Maybe I was misreading or misunderstanding.

[@danvilela]

Tests are for bad programmers. Peace ✌🏼

[@gljames24]

Didn't know about atomic commits, but I feel like I already do that naturally.

[@katanasteel]

This help your butt when you also want to leave the place a little bit better that when picked up the hunk of turd that's the company's legacy code

[@Holobrine]

I like making smaller commits but pushing them in batches so people have to address all of them together and don’t come at me for stuff I’m already doing

[@theIbraDev]

main benefit is that your git profile will look very green.

[@anj000]

Wait, so he is rebasing, but not on master? I'm not sure I'm following. So he still makes normal merges to master from his feature branches? And he means that he rebases his local branch onto master before making the merge request? This is so confusing.

[@d3stinYwOw]

Atomic git commit + TDD (AMDD better IMHO) sounds like something great to be fair :P

[@codeman99-dev]

7:31 Point of fact: "revert" is way more inclusive than just the `git revert` command. The term "revert" is simply a reversal of history. That includes `git reset`, `git checkout -- .`, and finally `git revert`. The revert command only exists for reversing a historical patch quickly. That's not the conversation here, or at least I hope not. I would hope the author means active development. The current work tree, stage, and most recent commit (or two).

[@ruukinen]

As a tech lead I do revert often enough that I have how to do it in working memory since often shit is hitting the fan when I do, but I do those other commands nearly daily when working on something.

[@LukeAvedon]

I love TDD.

[@shadamethyst1258]

It feels to me as if TDD or in general "test-first, code-later" is the dual of "code-first, test-later". You can solve the problem in either way, but sometimes it's faster to solve it in one way. The fastest way might require you to switch between the two. Am I off the rails on that feeling?

[@HrHaakon]

A real life problem with TDD is that it assumes you know what the finished product will look like. If you don't you might want to explore it first, then nail it down, then write tests and code, and only when you're done start the PR. On the other hand, if your task is basically "here are some unit tests, go make them green", then that' s fine I suppose. But at that point, you're a human ChatGPT clone, not a programmer.

[@ruukinen]

@@HrHaakon Often you have acceptance criteria that you can create test for before hand though. Like this API needs to return this object with these values and then you code that API to conform to those tests. When prototyping I don't think TDD is particularly useful.

[@rotteegher39]

I was on the stream)

[@ThePrimeTimeagen]

fun stream

[@edd6927]

I lost it at "Galacticus" lmao

[@nuttygold5952]

This is actually insane, the guy has invented a word for basically the core concept of git. "A single irreducable unit"... so a commit then?????

[@MorningNapalm]

Yes, lol, but no. You know what he meant :D

[@Blubb3rbub]

I feel like the usefulness of TDD has to be put in context of what you are actually working on. If you are writing business logic or a website or something, it's not useful. If you write some sort of algorithm or optimizer, and you need to tweak it, so it produces the correct output for a given input then it can work (e.g. Sorting, searching, matching, path finding, propagation), because you can put all the errors you encounter into easy test cases and confirm that the tweak does not reintroduce other errors. But that does not work for creating a "system" or "behavior". I did TDD once when writing an algorithm for a Minecraft mod that calculates "prices"(EMC values) for every item based on the recipes and a set of initial item costs. For that task it was an excellent choice. But something like that rarely comes up in a day job 😢.

[@handlechar568]

Depending on the domain, your core business logic may be composed of multiple algorithms to transform and pipe data, encapsulated in a single library with few dependencies and a minimal need for mocking, which would be a perfect candidate for TDD, or at least very high test coverage.

[@HrHaakon]

​@@handlechar568 I mean, even if I dislike TDD, I do have tests that cover anything even remotely hairy. The opposite of TDD isn't not testing, it's testing after the code is done. Then there are people like me who write the tests in tandem with the code.

[@haspe7439]

I am so glad that I feel like that I am actually right. I've actually gained a reputation to be the guy who refactors everything, constantly. Also about TDD, I thought I was just inexperienced and "stupid" in a way, that I couldn't really apply that effectively, but nice to see that others share the view that it's not that practical.

[@frydac]

I do think TDD is a good exercise to do when you're a newer dev: it helps you think about testability of your code, which can improve many aspects of it. Mainly making your code depend on as little as you possibly can, potentially extracting 'atomic' functionality from some abstraction so it becomes more easily testable. Which makes your code more easily refactorable and flexible. Strict TDD is just not viable in many situations, but I do always consider testability of my code all the time, and I think it is a good idea to write (at least some) unittests very early when starting a new abstraction, in order to have a way to experiment freely with the code in a fast feedback cycle, if you plan on writing unittests, which also depends on a number of factors. In my job, embedded audio processing, I unittest just about everything, as it is fairly easy to do and the ROI is large. But I can imagine in more frontend stuff, you'll rely more on different kinds of tests, that may be better suited to create somewhat later in the process.

[@haspe7439]

@@frydac This is a very good point. I also feel like that we should aim into implementing a test suite, that is covering most important and core functionalities, and this also makes onboarding new developers easier. If we can trust the unit tests will catch the most "dangerous" bugs, maybe onboarding new developers to the code base would be easier. Could there be a middle ground of applying the good concepts TDD in most of the scenarios?

[@TheBayru]

I thought TDD was mostly great for working with clients; define use cases, write tests to test use cases, write code iteratively 'till tests pass...

[@MrLowbob]

what?! a video that didn't end with... THE NAME?! ....

[@mitrichaka11]

TDD is a fun killer

[@MH_VOID]

Hell yeah watch me make 10000 typo-fixing commits a year

[@sck3570]

do you really do that?

[@masoudmohajeri8678]

what is sectionizer ? I tried to search but I didn't find it !!! 0:36

[@smjonas8616]

It is called tmux sessionizer

[@doresearchstopwhining]

It all depends on what you are doing. When making big refactors, I love to see the diffs all in one place and as such, I end up doing monster commits. Thats just me, probably wrong though.

[@portersky]

I mean, you could do small commits then rebase it later before putting it into the master branch.

[@doresearchstopwhining]

@@portersky Yeah but then you have to rebase it to actually see the diff. Like I said, I'm probably not doing things ideally but for me I like to see all the diffs along the way.

[@7th_CAV_Trooper]

Weeks of work. Single line commit description, 'rewrote entire shit show from scratch". PUSH

[@diogo405]

oh yeah, smaller commits and running all your tests as well, very productive 👍

[@sorvex9]

??? Rebasing would only limit your chances of reverting as you have potentially squashed and merged several commits.

[@runamonk]

If you're having o revert a lot, you're doing something very wrong with your planning.

[@TheHTMLCode]

By the definition of “it can be 1 line or 100k lines” can an atomic commit not just be categorised as squash-merged branch? If your tickets are well scoped and your changes are intentional and focus on a single piece of functionality, then a lot of us are already doing this 🤷‍♂️ maybe I missed something

[@TheHTMLCode]

I listened a bit further and I agree with not footgunning yourself by committing frequently. I totally agree with this as you’re “checkpointing” yourself as you go “everything was green until commit hash abcdef”. I’m surprised this isn’t how people are using git already though 😱

[@Daniel_Zhu_a6f]

TDD is helpful because you can anticipate the requirements quite often. Consider this: when you write a parser, you will probably need a deparser (at least for debuging), when you need to fetch data, you will probably need a function to send some data back, and so on. you have a x == undo_stuff(do_stuff(x)) test for a ton of things, and you know that for sure. then you probably have a lot of category theory stuff (like groups, monads) where you can anticipate some additional properties. This covers most of data structures, data processing and IO.

[@skolex3121]

Did anybody else get the half baked reference at 2:19?

[@Gahlfe123]

TDD is something that sounds cool but in practice , its justt as you say, its hard to make test for future cases that havent even happened yet. seems like TDD goes hand in hand with overly planning a project. wondering how and where you would use tests in a project that isnt based on TDD?

[@ThePrimeTimeagen]

i usually think about and play around with solutions for a bit, then i write out some tests _if_ the code is hard to get right the first try

[@darylphuah]

as long as we're not too dogmatic about it, TDD is actually a great approach. Just keep the tests high level to meet the basic requirements. You can fine tune the tests as you go along. Once you get used to it, the initial test suite normally doesn't change much. Another way of thinking of TDD is pseudo-coding your happy path in code. Once you got that, you fill in the implementation details bit by bit.

[@dealloc]

@@darylphuah What's the point of writing tests first if you're going to "fine tune" them later on. And by fine tune, we do mean, changing every part of it because the implementation ended up more complex with the initial approach. I've said this in another's comment; TDD only really works well when you know every part that your implementation touches inside out and you know (or control) the requirements. Otherwise it's just "regular" development with tests.

[@darylphuah]

@@dealloc you will be tuning your tests initially because you're not used to the process. Once you get used to it though, you will find that you hardly change your initial tests. Still, we live in the real world so there will be times you have to do fine tuning. Another important distinction is that by writing your tests first, you are closer to testing the requirements vs testing the code. Its often too easy to write tests that fit the code, which makes the test brittle. The reduction of cognitive/mental load is also significant. Since the tests already map out the expected flow, you can tackle each piece one by one without worrying about the rest. What has been implemented already have tests to guarantee its working and those that havnt can be mocked for the expected results.

[@alexkozliayev9902]

You shouldn't write all the tests before the code. You literally only need to write one test for current functionality, make this test pass, then make test for another aspect, etc.

[@SArthur221]

isn't TDD literally bikeshedding?

[@laughingvampire7555]

one commit to fix each typo

[@JeremyAndersonBoise]

14 teams later

[@presDev]

"i rebase dog" ahahah

[@cubbucca]

I dramatically increased my productivity by allowing incomplete commits that dont let my test suite follow through. This mean I can commit on a timer and walk away at any minute, when I return I can review my commits and continue working. I can work on multiple projects without the need to follow anything to completion. Often a problem is solved very quickly, but implementation takes time, incomplete commits allow solving without implementing.

[@johnjackson6262]

That doesn't work well when working with multiple developers.

[@galafendouorden]

​@John Jackson If we are talking about single feature per developer, than it works as you should have separate branch for your needs. But it won't if you are working on same feature unless it is separated by domain/environment which is more common at least in my experience

[@johnjackson6262]

@@galafendouorden You still need to fix the history later on

[@galafendouorden]

@John Jackson what for? making commit with current change while switching to another task, you only need to get back to this branch and finish the task later on, nothing to fix in history

[@Yay295]

Why not git stash?

[@DelkorYT]

more commits = payraise at X

[@JorgetePanete]

How much do colleagues need to communicate? let's say we are doing each our branch, and to combine each other's work later he keeps his version of what I changed and I keep mine, because we did not communicate

[@AnarchistItachi]

Got a like, purely for the statement "I rebase, dog" ❤ merge commits need to go behind the barn 🙄

[@Waine2000]

This guy uses effect phrases in every possible takes. Feels like only provoking the reacer

[@dandogamer]

Atomic commits aren't always revertable tho e.g you make some config/db/infra change

[@Soppybobs]

In terms of .env or .gitignore? Cause I’m doing a pretty intro aws serverless project and my .yml config can be reverted easily.

[@caltissue141]

that's why you changelog those things and re-run your create command after the revert 😉

[@frustratedalien666]

Eh, I have like a hundred commits on my feature branch, then I just interactively rebase/squash them into one commit and pretend my work looks neat lol. It has worked for around a decade now 🤷‍♂️

[@maddsua]

Rebase gang squash bang here 🤠

[@emjizone]

2:57 Greatness ain't absolute (not even America's greatness, so imagine... 😆 ). I mean it's *not an intrinsic feature.* *Everything is great* at something, but *none can be great at everything.* So it's basically *a matter of what you care about most.* Simply tell us at what TDD suck.

[@rikschaaf]

I reverted today. (I even reverted my revert today)

[@ingloriouspancake7529]

Jippity

[@dealloc]

i commit every character change so reviewers can easily review code character by character for better and faster software

[@ianriva7902]

What is the correct way to rebase to avoid force pushing? You said don't rebase master

[@handlechar568]

I assume he means rebase locally so that you can do fast forward merges (or just push) to dev/master/etc.

[@animanaut]

opinions differ, but i would generalize it to any remote branch. not just master. do locally what you want, but dont eff with already shared branches. ever

[@rakeshravindran3147]

Atomic git commits are idiotic. The only reason I use something remotely close to that is when I am whipping out POC and needs to switch direction and try something else. Even then, I use a mix of branches and commits.

[@alexkozliayev9902]

Isn't it just a common sense use of git or other source control software?

[@TrippLilley]

`git bisect` is way more useful with focused commits. (Same w/`git blame`, as another commented below).

[@amadeusk525]

It's the best aspect about it. Git bisect imo works its best when doing atomic commits and never squashing/merging, only rebasing. I'm really not a fan of other Git workflows

[@nexovec]

Too small is a problem, ask anyone.