You're Not Qualified To Have An Opinion On TDD | Prime Reacts
ฝัง
- เผยแพร่เมื่อ 12 พ.ย. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Reviewed article: blog.boot.dev/clean-code/your...
By: Lane Wagner | / bootdotdev
Discount Code: PRIMEAGEN
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts
#ad - วิทยาศาสตร์และเทคโนโลยี
![ทัศนศึกษาโรงงานผลิตโค้ก [THAI/ENG SUB]](http://i.ytimg.com/vi/M9y-TJBNem0/mqdefault.jpg)
"However, when you listen to Prime, Dax, Theo, or myself give opinions, you need to remember that they're our opinions, not yours."
Yes I completely agree with that. Wai-
gotcha!
GOTTEM
who is Dax and Theo
"5 years = Senior", now that's a hot take :D
haha I heard that and thought , "oh fuck I'm supposed to be a senior by now?!?"
1 year senior speedrun
granted, some jobs will give you senior in the title pretty quickly.. but no, 5 years does not a senior make, regardless of titulature
I think it depends on how good you are dealing with things at scope/scale. Number of years shouldn’t be the #1 factor
@@obsidian7295 It's not the #1 factor, but it's a great overall predictor. Very few people I've seen that had the label "senior" with < 10 years who could actually cut it. Granted, it's anecdotal. I've seen inverse too, but either extremes are few and far between...
I don't think pragmatism is a problem at all. In fact, I think it's a great way to focus on the problem at hand and not get caught up in ego. Sometimes, that means iterating on a nuanced topic to figure out what a reasonable approach is for your use-case. I'll meet you halfway though: Using "it depends" as a cop-out to avoid having to make a decision, or even worse, to dodge having to admit you don't know what you're talking about in the first place, then that's a pretty bad look. That will for sure impact your performance as a developer.
Same. I have a like towards something but I don't religious follow it because often time you just find yourself in situation hard model some problems and would have been nicer to include some room for flexibility
Yeah, I reacted to this as well, and I agree. As a cop-out, it's of course not good. But if you can say "it depends" and also make a case for why it depends, and on what, and have an opinion on what to do in each/most cases, then it's probably a much more valuable and grounded opinion than the religious beliefs of "X is always best, no matter what"
"It depends" is a fancy way of saying "I don't know". While not knowing something is not a bad thing, saying "it depends" will prevent you from actually investigating a topic, which is bad.
@@elzabethtatcher9570 if you say ”it depends” and just exit the conversation, then yeah, I’d agree you might as well have said ”I dunno”. So don’t do that. Express your nuance and keep the conversation going.
@@elzabethtatcher9570 L take
The second part of the quote is often dropped... Strong Opinions...Loosely held. You gotta know when to alter/change your opinion. This is an undervalued strength - not a weakness.
Fun faction - when interviewing a senior I like to ask a 2 part question... What technology was considered great that you thought was lousy - and you were right. And then what innovation did you hate, and then came to realize you were wrong ?
Exactly the point about TDD. If you understand the requirements, TDD is simply a way of testing said understanding. If you don't understand the requirements, why the heck do you think that your tests will be accurate? Basically, TDD is a way to work out and validate requirements (IMO).
This is exactly what's wrong with TDD's critics: they don't know what the fuck they're doing, and they think it's the process' fault that they don't when they struggle to come up with that first test. They like writing code without a clear picture of the requirements, and they never reflect on why their initial releases are buggy shitshows.
Sorry but I'm not just convinced. If you are talking about end-to-end tests, sure, talking about requirements makes sense. But if you're looking to make the development experience faster and more interactive, you need to emphasize unit tests. And therein lies the rub because it usually takes some sitting with the problem and trying out some stupid ideas before I even know how to break up a problem and therefore what to even test. That's what critics of TDD are talking about, and that's something I hardly ever see TDD advocates address.
@@isodoubIet You try out stupid ideas in throwaway proofs-of-concept after following a tutorial or reading some unfamiliar API's documentation. It's that simple. Consider it "addressed." There's no need to merge that experiment into master and ship it.
Once you've learned from experience, you should be able to think ahead well enough to know what behavior you want, which means you know enough to write a test. If you find yourself unable to do this, repeatedly, you either have more to learn or you're not learning.
@@CrazyHorseInvincible Who said anything about merging? I get the feeling we're talking about entirely different things because you in no way addressed what I wrote.
@@isodoubIet Before I start commenting about your reading comprehension and try explaining to you why my response addressed what you said in its entirety, let me ask you this: did you get tripped up seeing the word "merge" and then just stop reading the rest of the comment? Did you just assume when you saw "merge" that my whole comment must have been about source control?
I think opinions come from traumatic experiences that devs accumulate over the years. Jr devs just don't have enough production experience to be scarred by bad decisions and form opinions post hoc.
"Frontend, backend, mobile, embedded, etc." Wow, that's an extremely big "etc."! I would definitely put mainframe and HPC as two completely different categories there. High assurance software, like in aerospace, is probably a completely different ballgame also.
embedded itself is a huge part
seriously, writing the software for an led controller or a monitor are two pairs of shoes (including the reliability)
@haskellelephant There's a found a problem section in the article, be our hero :)
"I'm a glue engineer". Missed opportunity for, the name... is the Gluagen!
This video hurt me. Thanks! Nice to see I'm not completely numb to searing burns.
Pair programming is not fun but quite effective. Only in moderation because it is also quite exhausting.
And the rest too, nice takes 😀
My first job was working on test infrastructure of mission critical software and TDD is actually great, once you have it set up, which is a pain. When you have a bug, you create a test that is guaranteed to reproduce the issue, then you modify the code until the test passes, then you run it through every single test to verify there are no changes. We were legally required to do so, but it made development very easy. Switching to a startup web company, it is shocking to see how little test coverage there is and how frequently things are broken. Granted the first situation was a offline program and didn't deal with dozens of microservices so I get how that can be harder to get right, but I get so much stress from deploying something now and holding my breath hoping it doesn't break anything because we have little testing. I'd much prefer the guardrails of a TDD environment
On a startup you often don't have the time luxury to get high test coverage, things change so rapidly to the point testing begins to be a burden rather than a benefit, but you are right, getting to test for bugs you've encountered on the past is really nice and it often gets you closer to generalize over those test.
Worked for a big company that required 80+% code coverage on the front-end. Most of the code was UI written in React and countless libraries. Testing that was a pain, gains were not that substantial. Guardrails of a TDD are fine when they make sense.
@@Salantoryoi prpbably were not testing it right and you tried to test the implementation instead of the behavior (eact eucks and thats how you should test it).
@@theangelofspace155 Ah yes, the standard "you were not doing it right" mantra. Have you considered that JS UI frameworks are just not that easy to test?
I too have found that when you're dealing with changing (or more often obscure) requirements the architecture/approach changes so quickly that maybe one day we'll be stable enough to consider legacy testing. I work at an org of all jr's no seniors and I'm more senior than most. So I'm probably the dummy who has opinions he hasn't earned
I just want to appreciate the fact that the time length of this video is 13:37 😂
1336 for me. Feels bad.
boomer :D i think no one who was born after 2k knows what leet code is :D
@@thomassynths TH-cam eats exactly 1 second from the counter in player in every video.
Actual duration is 13:36.8. I see the floored version, that is, 13:36.
That article is a goldmine of ideas and opinions. Thanks for bringing it to my attention.
1:16 Oh boy. Right of the bat, I have to disagree. The more experience you get, the more nuances you're exposed to, & the more your answers start with, "It depends."
And it is addressed further in the article.
I have opinions. One being that developers spend a lot of time arguing about crap that doesn't actually matter. Sometimes it feels like people are searching for a silver bullet. There isn't one. It's tradeoffs all the way down.
This is so true.
It's very cringe to see juniors having strong negative opinions about something they are yet to experience or understand.
That's what this channel is, pretty much.
The amount of geeks in my uni classes obsessing over neovim after using it for 6 months is crazy
What an honorable man you are! My most high respect to you Mister Prime!
So I have tried htmx. Loved it. And I did a little bit of heresy. I added JSX so now I can use JSX with htmx and that's awesome and even my colleges loves it. If it looks like react 😂
my brief time in programming has taught me that when you strip away all the opinions and subjectivity, only a few raw truths remain:
1. every language is ass, especially the one youre using right now
2. every project built with those languages is therefore also ass
3. likewise, anyone who calls your language/project ass is an ass
4. there are no right answers, just answers that are less ass than others
We use a fair amount of Haskell at my job. Just don't use it for something that requires insane throughput.
How you came to the conclusion Haskell was the right tool for the job, and what do you use it for? Asking out of curiosity.
I love Prime. He gives me my daily dose of assumption challenges. But I'm qualified to comment on TDD and if TDD isn't working for you when you don't understand the problem then you're doing it wrong. TDD is a method of rapidly iterating on the pronlem domain and the whole point is for the dev to learn about the domain context.
2:04 After 40 years I started to become a bit selective on which topics to have strong opinions on and not, I have my prejudice, and my preferences, yet I also have my curiosity wondering what other people may come up with. Why mongo when there are FileMaker ERD, PostgreSQL performance, and elastic search DSL?
Convenience, Objects/Arrays inside records, text search and aggregate functions that are really nice compared to the things you have to come up while working with SQL. For schemas I usually work with mongoose that helps with the unstructured aspect of NoSQL
@@sebastianperez6124 Yet do you find the result satisfactory? If I had to go that route I would choose CouchDB over mongo, then again having data stored in both postgres and elastic search does give an edge I have not yet seen in mongodb. Also there is Neo4J if you need something to cater for edges. Then again I'm from the non-tech company with internal software. And I'm for issuing monoliths as microservices in the deployment stage.
Point 2 was definitely me when I started out and BOY was I annoying AF. Leveling up involved a lot of learning how ignorant I was, and embracing that, building up a foundation for opinions (usually by _learning_ from screwing up) instead of holding unfounded opinions.
I had opinions after university, and as a professional my opinions keep getting validated. I have no idea where tf people find juniors that know nothing.
Perhaps you are a prodigy.
I think it's more about how loud you were about your opinions. If they get validated and *then* you say "I think _ because _" it works because you actually have the "because"
@@SimonBuchanNz Yeah the "why" is always the most important part of the opinion. And the reason why opinions without experience is bad is because a lack of experience means that you can't articulate that "why."
do u have ur own team at netflix. id love to work on your team because I hate TDD as well. usually the people pushing it dont actually coded and think it sounds good on paper.
It's so funny to hear Prime saying "that's the greatest take of all time" in every single video. lol
In my mind I always think, "I love TDD! How else could I rest easily knowing for sure everyhting works?" but hearing people complain about being forced to do it I realize my TDD practice is very loose. Typically I write a bunch of code to roughly put all the pieces in place-- somewhere between functioning code and pseudo code; I know it won't work as-is but it more or less serves as a blueprint. Then write a bunch of tests based on these components--which I know are full of bugs and typos and don't work yet--and then keep iterating until the tests pass. TDD super-lite?
I have found when I'm doing something totally new, and I know little about how it'll all work, I'll write a test. And then spend 2 weeks trying to figure out how to pass it.
Right, loose. You lose the assurance that any given line of code is backed by one or more tests.
I havent laughed so much on any channel, ever. thank you
I personally decide whether do TDD or not using bottleneck-first approach (or let's start writing the most difficult and uncertain parts first approach).
When I have no image of implementation, I write codes first.
When I feel debugging or testing is more difficult than writing codes (for examples when it involves external API calls or complicated data setup) I write test codes first.
I am a grown ass man and i just went out loud. I want to be a glue engineer. Glue engineer. GLUE ENGINEER...
I only done SCRUM once for real and it was awesome. I think people take it too seriously. If you do "chill SCRUM" things are pretty nice. I think the key for my team was that each role was an engineer in the team doing real coding work. If you made things bad for the coders you made it bad for yourself. I guess it might be more agile than SCRUM, esp. since we allow heavy modification of SCRUM principles, basically Retrospectives rule everything. Hate that annoying meeting? Alright let's remove it!
I call Agile/Scrum the good ole 80s and 90s “cowboy workflow” that managers used to hate. But we made more progress than even now with all these simple programming languages and frameworks.
My old manager called it “the case of beer method”. Sit with a case of beer discuss the problem at hand and afterwards we all know what to do.
I love working with my scrum master. Ceremony are good for we weirdos to interact withother instead of been in a dark room, not trying to pair program the whole day.
"chill SCRUM" is not SCRUM, it's just a flavor of Extreme Programming
My experience is as long as you remove the sprints your are fine. Most of the bad parts of scrum are coming from people tryng to fit everything down into this artificial construct, called sprints.
@@05xpeter my trainer always said: “you can’t continuously sprint” so the fact you continuously are sprinting is impossible-we need to and a jog and a recovery part too 🤣
As a person who has never programmed in Haskell in his entire life, I do, still have a reason to hate it. I use Arch btw :), and whenever I let even a small haskell program onto my machine, it immediately comes with 300 MB of dependencies spread across 40 different packages (I'm looking at you, shellcheck) and my list of updates becomes so long to read because it's a wall of Haskell packages. I hate Haskell strictly because of it's dependency management. It's the same reason I hate PHP (at least it's less disk space, but still includes the update wall of text) and to a lesser extent (smaller wall and less disk space) Python.
At least Node, Go and Rust have the decency to have independent package management that doesn't interfere with my OS upgrades. Go and Rust is even better in this respect because if the Go or Rust developer give you a pre-built binary, then you have to install zero Go and Rust dependencies, including the compiler itself.
So, as a non-Haskell dev I can definitely say, I hate Haskell.
A little bit confused about what the author means by "[used it] in a real project". Does that mean I can say that I hate react if I rebuild my portfolio in it?
Well it normally pretty much just means "more than a demo", so if you *reasonably* hate React, you probably already have used it in a "real project"
The pragmatist has a place when you are asking generalized questions. There is no one right way to do a thing and different clients can have different requirements which lead to different optimal solutions. Having a single dogma that doesn't work for your client won't end well... but that's the difference with being on a singular team with a single product versus a consultant working on tons of different products and platforms with different dev teams.
"I don't like Scam Bait"
Me watching Kitboga in another tab: "Sorry, Prime says you have to go.."
I disagree with a lot of your opinion. But here I am watching and liking your videos.
My goal is to create discussion, and I'm okay with having bad opinions
Lane is the goat, his go course on top tier
what you'd call a "glue engineer", we'd call a "floater"
Pragmatists DO have opinions, but I tend to agree with you, I'd rather deal with folks who have opinions based on their own experiences (even if I don't agree with them) rather than deal with the opposite.
what's wrong with mongo and what is the alternative that fixes that issues without creating other issues ??
What's a TIDDY?
"When I really understand the problem TDD is fine, but when you don't understand the problem TDD is godawful." You've expressed this several times recently in different ways. You also recently said that you like prototyping, ie, you experiment to understand the problem then you throw it away and start fresh (bravo, btw, hardly anyone actually does this). What you're missing is that there is nothing about TDD that says you can't do this. As much as I HATE how Uncle Bob generally expresses himself on this, he does say it best with: "Don't write a line of **PRODUCTION** code without a test." You are absolutely free to prototype and experiment to understand the problem. Agile even has a term for this: a "spike" (from "to drive a spike through the problem"). At the risk of sounding like I'm trying to give you an old "gotcha" here, if you've prototyped and experimented then now you are in a position to use TDD in that same way you did that one time that you said it was great: armed with a good understanding of the problem! This is what TDD was meant to be and still is to many people. It helps tease apart a more technical design-you'll uncover lower level problems like where to draw boundaries, how easy you API is to use in isolation, and when functions are maybe doing a little too much (beware of many single-line/single-user private functions, though, those are pure evil). There is nothing in the source material that says TDD was ever about designing a complex system from the first key-stroke.
That is a great article. Junior devs (like me) gotta remember that our field of vision as to what "is good" and "is bad" is really short and really narrow.
Our opinion is going to be based on limited relative knowledge, and Seniors are going to have a large amount of "footgun" experiences that crafted their opinion.
It might be that HTMX and Go are amazing and React+Node is going to rot the brains of the youthful CS grads.
But I don't know HTMX and Go. I know how to make some React Server Components "do the thing" for grandma's family picture website. So, of course it's the greatest thing since sliced bread. It's what I know, and I haven't had my footgun experience (yet). :P
I think having opinions as a junior is good as long as a always keep in mind that you don't really know stuff and you only have those opinions so that you can engage with the topic more and learn stuff faster.
I really like tailwindcss and I have a strong opinion about so that given the chance I could discuss/argue if it's a viable approach and learn something new.
@@huge_letters fair point. A junior with no opinions probably also sounds like they have no knowledge.
I guess a junior should do their best to have a strong opinion about a thing or two, with good reasons to give to back it up. But maybe not on every piece of the tech stack. ;)
As a junior dev, I have lots of opinions. Mostly they're opinions about how I hate everything I'm trying to do because whatever it is I'm trying to do, no matter what it is, is probably the wrong thing. How do I have rawaccel on Linux? IDK, I'm beginning to think that trying to have mouse accel in the first place is the wrong thing.
That Haskell joke was next level
THIS. EVERYBODY NEEDS TO READ THIS.
Who is Dax? What is name of his YT channel?
Who's Dax?
Some rapper, maybe?
I don't have strong opinions about anything, as I have been able to understand any given tech and complete all given tasks with them. As long as it works, I'm happy.
...or maybe it is the fact that I have done almost exclusively frontend.
lol! Did you really think we wouldn't notice you pulled the outro from another video???
@4:00 i thought he was going to say "the talks so much shit he make me wonder if i also do"
New is always great for Tech TH-camrs.
like your videos a lot
I like the idea of TDD as this first line defence against bad code, but after a few tries I decided to just leave it alone. For prototyping and especially UI - especially especially UI built with frameworks - it feels like an additional and completely unnecessary work.
same, maybe I just can't do TDD, maybe I don't have patience for it but I really see no use for UI TDD. Every example out there just passes some values to the component and checks if its shown on the screen. Like, I can guarantee you I haven't forgot to pass all the required props because my typescript wouldn't build.
Maayyybeee it's useful when you have a dedicated designer that designed every component very carefully based on idk eye tracking from hacked smartphones or something and you have to copy the design into the UI exactly. I don't have that luxury, I make internal software and I "design" stuff as I go(What I think looks okay(spoiler: it usually looks bad)). There are no design requirements though and functionality requirements are always REALLY loose at first(the management doesn't know what they want exactly)
For backend and algorithms though.... I wish I knew how to write good tests fast. I once wrote an big db migration (including recalculating old data into the new format). Tests with mock data calculated into the new format by hand saved me hours writing the algorithm and huge amounts of uncertainty.
That's because TDD is not meant to be used in those scenarios. If we are prototyping, we can't do a Test First approach since by the nature of prototyping, we don't know yet what to expect. Same goes with the visual aspect of the UIs. It's really unfortunate that there are so much material of TDD but a lot of it misses the nuances and gotchas.
I recommend reading Kent Beck's Test Driven Development by Example, it is arguibly what helped bring TDD to the spotlight
@@igorordechayou passed all the props, but did your conditional render component render rendered?
@@JArielALamus THIS! Robert Martin has also said that essentially he doesn't test UIs. He just detaches them from their text, for some reason. I still don't fully get why.
@@JArielALamus Exactly. TDD seems to be one of those things that people assume they know what it means just by the name. Otherwise very smart people keep reiterating the same false information. TDD for prototyping make zero sense. I do use it to get going on UI but it's not something I push on people (that is more BDD anyway).
who is dax? can someone link me
And here I am learning scrum in my company 😢
As a Senior Developer of 11+ years, My opinion is that some people who have strong opinions are just too opinionated. IMO.... 🤣🤣
There was so much crap I learned as a junior dev that everyone is now realising was total crap; what are you supposed to do when you can't trust your community, peers, elders to lead you in a healthy direction? Forget coding, that, sadly, seems true of the world today.
I listen to the people who have actually done practical work that's inspiring. Tangential example, look at how morbidly obese or frail some "health ministers" in the west are. Should you take diet advice from them or any random dude on TH-cam who's like 40 years old but still looks like a 25 year old greek god. Same idea applies to mentors in any field. I don't trust moron academics who are stuck in theory land who haven't actually done much, if any practical work
Well I'm sorry to say but most people are not geniuses, so if you want that kind of guidance you really have to seek it out. You probably won't find it on Twitch either XD Usually you can learn a lot by making mistakes and learning from them, but large companies have a lot of momentum behind beurocratically enforced mistakes so sometimes people can't learn in those environments despite working in them a long time. Just keep doing the wrong thing until you think it's right.
I've never actually done TDD outside of an interview, but I could intuitive know that TDD's usefullness is 100% correlated to how deterministic the problem is. I mostly work on research/experimental projects so TDD is virtually impossible on those.
Thumbs up for mentioning Kitboga…
We would be remiss if we did not note that there is a difference between not having an opinion and being so jaded that you don't care to form opinions.
Almost everyone saying they do Scrum is doing NotScrum. I got a chance to do Scrum one time and it was wonderful. However, there is zero chance you will get to work with a team and leadership that cares to understand it or the courage to attempt it. So in practice, yea, avoid scrum at all costs. Just get a kanban board up and pretend to update the ticket here and there.
Well I do, we do scrum, our scrum master is very good eith the ceremonies. And we love scrum (as junior dev, but for what I have seen seniors dev love it as well).
@@theangelofspace155 I only advocate against it now because of the tendency for cowardly managers to implement it incorrectly. It's absolutely possible tho! gratz on the unicorn! Have you or anyone on your team read "a scrum book: spirit of the game"? It's where they put all of the prescriptions they left out of the guide.
Theo mentioned
Haha glad you saw
Embedded programming realities:
1) What is that C "standard" you are talking about? You mean that C-dialect that was implemented by Jack the employee at Microchip Inc in the basement of his apartment in 1994 and throws errors when you create a variable name with more than 10 letters?
2) Do you know what happens when your callstack grows into your heap?
3) Do you know how much memory is left when you call ONE callback on a microcontroller with 20 BYTES of memory?
Fun fun fun... I could think of a few more things...
20 what? How? Why? Don't CPUs have more bytes in their registers than that?
@@theodorealenas3171 Sorry... made a small mistake! 24 bytes. Check the datasheet of the PIC10F206! It is a cheap microprocessor with 6 pins, used to be less than 0.5 bucks, but now everything is more expensive! The world of embedded programming!
The glueagen
anyone tried ferretdb ?
love the transparency of your sponsorship, because some other creators mentioned in the article is not.
Kitboga & Prime collab when?
Tfw I was an htmx advocate for way over a year before Prime got into it, but now everyone thinks I'm just fanboying and pushing his opinions ;_;
stop fanboying and pushing my opinions
This one blog has enough good words for two months of tweets
While I enjoy your and Theo's content, agree on quite a few things, and disagree with at least equal amount I've still always gained something from the videos, like taking a look at HTMX and now start to slowly but steadily lose my hate towards HTML templating, moving more stuff to server... And yeah, I did get a job in web dev thanks to React as it felt least annoying framework to work with if you wanted to get a job few years ago.
Having worked scrum and kanban as a remote developer one thing I liked about scrum was it’s more of a community. Working kanban there is no downtime, no reset, no goal, just continuous work
But WHY do Scrum suck, and whats the alternative? I'm still a junior and has been questioned about the role as scrum master, and I feel like that could lead into me changing stuff. I hate daily standup that gives nothing, but everyone seems to just be on board with it. WHATS A GOOD ALTERNATIVE? Please help.
Why does Prime not like nosql?)
It's just that so many people have bad opinions that are short-sighted and narrow-minded, they have never considered that something they don't like might have perfectly good reasons to exist and they're just trying to use the wrong thing because they have no idea what they're doing. Personally I just dislike people who don't bother or can't even reason their opinions. The opinions are worth nothing to me if they can't communicate it, they might just as well be talking untrue baseless trash. And a lot of people take offense in having to actually explain their opinions and reasoning, as if they weren't the pope with unquestionable truths. Good opinions, great talkers and educators never fit in a tweet. Even though it's a demonstration of knowledge and skill to compact the message, soem messages are too valuable to fit in a tweet.
Doesn't even take a year to workout using mongodb was a bad idea.
0:59, no fun? It's awesome!
10:33, I watched a presentation in which some dude said his team failed badly with Haskell. And if we add to that the Haskell motto, _"Fail at all cost!"_ , we can assume many had tried... and failed badly!
I can imagine why: there's an obsession about pure f()s. The real world needs don't embrace that, most of the time. So 1 has to update variables outside the already precarious encapsulation of a f(), to fulfill the side-effect needs, so avoided by the language. Thus, everything becomes periculous. The disaster is just a matter of time.
12:50, what does that mean? Once you used htmx, you just use it, without an opinion? The perfect pragmatic tool?
I've worked on pretty sizable functional project that's in production. If you design it somewhat decently you're not going to have problems with handling side-effects. Side-effects belong to the outer layers of the architecture, most of the business logic is pure and can be in the inner layers. One of the problems with functional programming languages in the real world is that many people haven't had that much experience with them and even if they know the syntax and concepts they're still trying to translate imperative patterns into functional code (like what you described).
@@digitalspecterIf variables should not be created, everything could be pure f()s. But there are reasons why things once obtained should be memorized: either performance (expensive to get them again), tied 1 to another (need to be changed together), and so on.
Depending on the project complexity, there's not much space for pure f()s. i.e. if you turn the head of character in a videogame, changing his angle of view, even if not changing anything in the game, variables x,y,z need to change in some place, and memorized, because they'll be asked later.
Now imagine if you split the f(), which calculate changes, to make it pure, letting the variables attribution for another place. So we have the calculating and the changing f()s:
Pros:
- Code become more conceptual, where more actions have a name.
- 1 can shine in Haskell community, by making more elegant code.
Cons:
- Looses encapsulation: things that could better fit in 1 f() are now scattered in 2 or more f()s.
- Harder to debug: more places to look. It's needed to look the production of the value (pure f()) and also the attribution. They should be 1.
- Even worse: the rest of the project can now see and call those new f()s _(btw, C++ allows the user to forbid that)_ .
I'm not advocating to have less f()s. But create them just to feed the Haskell utopian idea to has a "pure project" is bad, dangerous, even prone to disaster!
Where's the part about Todd??
I was in a great project run in Scrum once. Skill issue
We need a HTML/HTMX tag
Since when does he do sponsored reads?
Cult people always say you will face hell if you don't subscribe to their beliefs. Agile/Scrum is one hell of a cult.
Using SCRUM in my current project, i feel 50% slower
1:49 pragmatism isn’t avoiding unpopular opinions or decisions. It’s making sensible real-world achievable choices rather than the theoretically best choices.
If two equally good things are being discussed, does it make sense to even have an opinion? I like to reserve opinions for when it actually matters and something really bad is on the table - otherwise you end up bike shedding and in endless discussions. Not having a strong opinion on everything gives your opinions more importance when you actually need to speak up
"Don't do clickbait?" Bruh my entire life is a giant clickbait.
2:10 honestly, i do not have an opinion on that
I dunno, I've pissed off a lot of people saying "It depends..."
I am gay and I have noticed people with the same sexuality as mine tend to love react, nextjs and idolize Theo😅. But straight men seem to like htmx and Prime more. Also noticed that people commenting on Primes twitch channel or also way way more smarter than Theos.
1337
He did it
Strong opinions loosely held
also it feels ironic that twitch uses mongo.. at least it did, i don't know if it still does
hello prime
i disagree with you prime but you are fun to listen :) and i respect you ... C# rocks ;)
Are we talking about senior developers or people with 5 years experience? :D I absolutely have an opinion what is considered "senior" these days
If the frontend looks that old, you know the backend knowledge is solid.
You guys are testing ?
I have to admit my opinions still are copy pasta of other people's opinions, especially Robert Martin's, and Prime's before that. Eventually though you observe that these people have richer opinions than they make it look like they do and you go "oh... Oh so there's no escape... How are we going to manage. Life is so complicated. I thought I had the answers!"
But when I do have opinions based on experience it feels awesome. Nothing hurts anymore!
Ayyy mobile shout out 5:46
Still pretty much not about TDD - but good post haha