Видео

I like it very much! Cheers!

Meteor JS

6:00 he he, RUclips

"How does it scale"? If you are working with real world things that have an inherent state and that are subject to interactions with the software, then representing these objects as instances of classes is natural. If these things don't have a state, then they should not be represented as instances. If these things are not subject to interactions without context, then they can be structs. If different kinds of things have similar properties or behave in similar ways, it might be beneficial to consider making sets of similarities "a thing" and name it. That's all there is to inheritance. If we name a thing and associate meaning with the name, then there is no harm in defining that the name represents the thing and that such things have this and that state and are subject to certain operations. If we are too uninformed or lack the capacity to recognize the nature of a thing and describe it formally, then we create scalability issues. That is a problem with our competency, not with the process of describing our understanding or the language we use to describe it. Nobody in their right mind ever claimed that understanding reality is easy and much less that a simplified model of that reality is expressive and correct enough to solve a problem based on our limited understanding. It's difficult. No matter how you look at it.

Ok and who and how decides who is in a any particular team

I been doing FE for 10 years now and I'm fu*¨ng depressed

I love you

A rectangle that inherits from EventEmitter? This looks wrong on every level. A rectangle is not an emitter. A DOM element might be. The modelling aspect of inheritance aside, exposing all features of an EventEmitter to a class like Rectangle is stupid, because once you expose it, you have to support it. Why would you do that? But you're not only exposing the interface (methods/props) unnecessarily, you also expose the whole universe of event handling complexity and vagueries (is it bubbling?). OOD/P is hard. The reason why it's hard is because it tried to model reality into a tree structure which it doesn't fit. Modelling means commitment. As soon as you manifest a program structure in an object model, changing that model becomes more and more expensive. This is what you dislike about abstractions. But that should not mean that commitments are a bad thing, it just means that you should only commit to what you understand. The alternative to commitment is flexibility. Flexibility, just like commitment has its price. It defers effort to a later point in time. It also increases complexity simply by not reducing it. Abstractions reduce complexity at the price of inflexibility. OOP tries to support finding common patterns in order to balance flexibility through polymorphism and rigidity through models. Finding compromises is where the real work happens in conflicting situations. OOP is not adding complexity, it's acknowledging it, much like all other paradigms. Structured programming was the attempt to progressively transform requirements into increasingly concrete implementations (top-down). Functional programming is the attempt to describe state changes in terms of results. Object oriented programming is the attempt to progressively extend the vocabulary describing systems (sets of data with related methods, bottom up). Each of these paradigms has their merits and issues. If you claim that a rectangle is an event emitter, then you should not claim that OO is bad, you are not using OO, you are abusing a technicality of a programming language (tool inheritance -> questionable even in OO circles).

As much as I want to care, i can't because it's an online casino. I mean it would suck and I'd drop CF if this was happening to a lot of mom and pop shops etc. But this, yeah idc

Thats a fucking terrifying story

I don’t like snake case because I hate having to use the underscore key

Bro really went :q! on his life buffer 😔

Agile as companies execute it and Agile as a concept are super different. The whole reason Agile was created is that knowing the requirements up front isn't possible. The person asking for the work doesn't even really know what they want. Seeing what you don't want can help you understand what you do want.

content good, but why this guy soo annoying

But there's 512 GB micro sd cards already?

Study proves what we've all known to be true for years. Feels good to finally have a study to quote from now when asking why we are still in the meeting.

Appreciate your transparency and candidness, hard thing to navigate these days. Keep being you dude, you're rocking the ether

Telling junior programmers that "Everybody is incompetent" is just another form of gaslighting. Also, so many people don't get sarcasm or subtle jokes any more, you snarkily tell some managers thatyou don't even know what you're doing and they just walk straight to HR to have your position terminated.

To be fair to agile; its been butchered. But yeah, we need a post-agile post-mortem. Watching...

They say 268% fails, but how does it fail? Budget, timeline, scope, ..? I'm no fan of agile (i.e. scrum) but that number is absolutely dogshit and worth nothing to prove any point. Other than that, valid points indeed

6 independent data points are enough for a statistic, change my mind. Also: look at Mr. Fancy Pant's team over there, working on a single problem at a time as a team instead of each team member working on several problems at the same time, lol.

There's a clear skew of Netflix engineer perspective - programmers are adults, they know what to do, if not, then they should be fired for their own good. In reality, there is an enormous amount of value generated by mediocre or bad employees in mediocre companies. In many cases, daily meetings are actually the only way to ensure people lacking ownership will communicate.

He missed an easy optimization, for loops are much faster in reverse. Cmon bruh, even a junior developer knows that you run for loops in reverse for maximum peeformance

getting paid for doing 13hrs per week on meeting profit

Feeding AIs human knowledge won't get us a cure for cancer. Sentient machines are a pipedream. AI seems more and more like a giant grift from big tech.

I do partially disagree with this - maybe we will see some devices that do this, but so far a lot of the push has been to do as much on device as possible (definitely from corps like apple). Likely we’ll see a mix of them on the market, but I doubt one or the other would be the only one

13:40 you mean managers would have 3 weeks without feeding their neurosis and sense of importance by micromanaging shit out every action anyone takes? They might become so bored that they start actually thinking and figuring out something helpful about managing people and how software engineering works. They might even psychologically mature beyond toddler stage! PS. I'm dedicated manual QA and waiting for 10 year when I become outdated. Might actually add AQA onto my belt in current place.

I’ve been using Chat GPT 4o because you get like 10 free prompts a day, and I have to say it’s incredibly impressive a big step up on 4 which Copilot uses.

I was about to go on a rant about how we do agile at the company i work for and it works good and then decided to watch until the end and what we are actually doing is what PrimeTime drew in GIMP. So good for us i guess

(paraphrasing) "having written your code it's easy to write tests with copilot", interesting, is there any reason you're not doing this the other way around i.e. TDD?

I prefer learning how to write good C code rather than learning how rust works and enduring the sheer complexity.

I don't like agile/scrum/foo, but this "study" is dogwater tier

Why not VS code?

101% agree. I wish there was another way to encourage newbies than pretending to be stupid.

The points in the video are fair and well elaborated. As a programmer and an artist I say it feels good to go back to simpler things (but not always for me). People who hate on other languages for no reasonable argument are the worst. I am currently using JavaScript mainly but I enjoy using other languages and have used them on different projects. So far I've used JS (and TS), C, C++, C#, Java, PHP, Python and even Assembly (had too much fun with this one). I really liked (and disliked) some of them but if anyone asks me why would I use a language over another for a certain project, I believe I have the minimum required knowledge to have a fair judgement and give a good reason. People just need to remember: they are all tools and all tools come with good and bad things.

"Readability is a function of experience". I agree, though it's also a function of brain chemistry. It's also a big FU to inexperienced people.

Saying "Agile is bad" almost always just says you don't understand the English word Agility. Working in an agile way means changing what doesn't work, which means that if you somehow realize whatever you are calling "Agile" is hurting you it is the agile way to stop doing agile. So agile cannot possibly be bad, since it will get rid of itself if needed. What other "product" out there does this? Imho the starting point a fresh team starts adapting from matters a lot though, since otherwise, you're just reinventing the wheel for project and team management each time. We for example start with a normal XP process and make sure each team has at least one person on it who has read and understood XP Explained and knows how the rituals react to change, e.g. if you do less pair programming you'll have to add in some form of code-reviews to compensate etc. Then the team can start adapting from a very good baseline to what they need specifically.

That's called frAgile, not agile

There is an entire industry built around celebration of incompetence and mediocrity. All those bootcamps, "get programming in 6 months" courses, all the grifter youtubers selling the idea that self-taught engineers are not any worse than the proper ones. Let them fail. There's no point resisting, too much money is in this industry. All we can do is make sure none of those bootcamp "graduates" get accidentally hired, and mock them at every opportunity.

I've experienced this problem with other Haskell devs.

You can keep the stand-ups really short, no more than 5 minutes to communicate what is needed. It's really just one sentence: I'm doing this. And if something happens what the others need to know, or you need help - you communicate this, and eventually set up an ad-hoc meeting or a pair-programming session. Again, very few sentences. In this form, it bothers nobody and is actually useful. As for poker - yep, just use Kanban. Pull stories from the backlog as needed. And nobody needs a scrum-master. I'm a consultant, and on my last contract the scrum-master fell ill, and later left the company. Nobody missed him.

33:40

Impossible for C# to be better than I think because I think it's pretty much perfect.

thing is this is totally as it should be. Agile is built on the premise of built small, fail often. And that is a good thing! In agile you fail and fix until you get it right. In waterfall you just fail.

From my experience, Waterfall was pretty garbage too and led to people faking their way through the "process" and just writing code. Agile became a buzzword so companies jumped on board. People started making money selling Scrum, so that became de-facto Agile. Scrum offers a bunch of solutions to problems you may or may not have. Instead of understanding the problems they are trying to solve, mediocre managers just try to stick to the recipe without understanding what they are doing. The team realizes the uselessness of the process and gets annoyed. But having a deep understanding of what problems you have and how to address them isn't something these managers were capable of to begin with. Maybe the problem with Agile was not enough flowchart instruction for adapting it to your situation. They incorrectly assumed managers were competent enough to figure it out on their own. And when I say "managers" I'm generally referring to the dysfunction that is the entire management structure at a large company.

At my last job I had a debate with a senior dev and the CTO about performance. They were adamant about the fact that today we focus on readability over performance and that modern computers are so powerful that our crappy node backend was just fine. I found it crazy from an engineering and craftsmanship point of view.

This is a complicated topic with, I suspect, a lot of confirmation bias going on. But I think what we can all agree on is that iterative development is the key. Agile…whatever. If you've spent any time as a consultant, you'll know that your ass is probably going to get kicked if you don't have some sort of end defined at the start. So what I find is you've got to define outcomes that are verifiable and they don't change all the time (but they are allowed to). So that's what you can report to whoever and that's kind of what you can estimate on. But it's extremely important that the tasks that you're actually working on are not the tasks that are being reported on. So in other words, it's just a high level map of testable business level outcomes. What actually goes on to make that happen? Leave the team the hell alone to figure it out!! The business doesn’t need to define far into the future. And the team doesn’t need to estimate or commit either. It’s just a tap of work. The other thing people get wrong is not making a distinction for a new “product”. New products should be designed by 1 person, and built by 1 person. MVP. Then, and only then. A team can study it and make the “good version”. Don’t believe me? watch Social Network. That wasn’t a coincidence.

this here is good example how you can overthink something to death. Clean code is nothing more than a set of 5 principals, that allows your code to be well understood, well tested, and flexible to change. These principals are clearly defined and are NOT subjective. If you don't want to write clean code don't. No one said, not even uncle bob, that you should code blindly by a set of rules. Its always about THINKING and EVALUATING and BALANCING how much it makes sense to adhere to principals and rules. But SOLID gives you a well tried out way to achieve code that is understood, well tested and easy to change - should you choose to use it, whee you think it fits. The overall nett outcome should be positive. Whats the point of the hoo haa here, is beyond me.

I don't have natural talent or grit. I was a "gifted kid" (undiagnosed ADHD and my hyperfixations aligned academically), and I just keep going between dry learning plateaus punctuated by huge (but unsustainable) learning spikes. It's taken me far, I'm not complaining, but it's utterly resistant to regular learning styles. I'm also happily employed :) I do feel incompetent quite regularly, but that's because the world is constantly changing (of course I'm not going to be familiar with a framework that just came out) and because I keep trying to seek out new aspects to programming, so of course I'm going to suck at those until I don't.

Very dishonest headline, not surprising though given the studies source is a book promoting a different methodology. In the study they say that they consider failure to be failure to deliver on time, not failure to deliver. There are many worse fates for a project than failing to deliver on time, in fact not delivering on time can be a key decision to ensure the success of a project. As others have mentioned, agile is very often misunderstood and incorrectly applied as well. People think that "prefer x over y" means never do y being the classic example. Nowhere in the agile manifesto does it mention that you must do sprints, or standups, or any specific thing that many companies think are required for them to be agile.