The Hidden Cost Of Speed

[@nyanray]

"don't tell me what to do internet moustache man" LMAAAOO

[@tirushone6446]

BRUH

[@baxterdevin]

Damn, beat me too it! 🤣🤣🤣 Flip, you are Legend. Never stop being you.

[@tiagodev5838]

Hahahaha this made me laugh so much!

[@flipmediaprod]

it aint much but its honest work🙏

[@WillyKillya]

​@@flipmediaprodnever change

[@williamtanardi3952]

00:32 Flip, truly a Godsent editor 08:42 L take, we will not be accepting this slander

[@rawallon]

8:43

[@flipmediaprod]

that was real footage btw

[@rick-lj9pc]

I agree that the critical flaw wasn't making a quick and dirty demo, the critical flaw was not saying hey if we want to do this for real we need to take the time to develop it for real.

[@HartleySan]

Early in my career, when I was too young and naive to know any better, I got myself into this exact situation. I learned a lot from that.

[@adammiller9029]

The critical flaw is not asking how they will use it. You don't present a bunch of ways something can be used. You ASK questions, you have to actively seek information when you do requirements gathering. You can't expect your end users to understand what you're going to code well enough to know what they need to tell you, so you have to ASK. You shouldn't even have a demo of anything at all until you've asked stakeholders about what they want, the use cases for it, and plans for the future. These are very basic things that would take AT MOST an hour to hash out. You can't skip requirements gathering. Trying to work on solving a problem you do not understand is a rookie move.

[@mangalegends]

I remember working on a legacy desktop application asking why things were done a certain way, and I was told that the application was originally a demo that was pitched and won a contract. Apparently after the demo they were going to rewrite it correctly but the customer said something along the lines of "I don't understand, I don't want it redone. I want what you just showed me and I want it now" so their hands were tied

[@HartleySan]

@@adammiller9029 Yes, a rookie move my company makes all the time.

[@deathZor42]

@@mangalegends it's on the sales guy to explain that to the customer if they can't your sales team sucks.

[@lesh4357]

I think that article was all over the place. When a marketing guy came to me wanting something to demo, I said "yes, but once you're finished with it, it's in the bin, trash, junk. It's a MOCK UP, a facade. It will never be added to, developed or used in any other way". He looked puzzled, I told him "I can knock some cardboard boxes together, put something round on each corner and say, there you go - it's a car. It may have a resemblance to a car, but it never will be a car, will it ! ". I explained it has no real functionality, no validation, no error handling, no way of integrating it with REAL code. I gave him an example of just ONE input field - what if the user puts this in, what if they follow the number with a character, what about a space here and there. I explained 90% of the code is what you don't see. He began to get the idea. I then confirmed everything we said in an email CC-ing relevant people in. I also got him to confirm via email that he understood it takes away from real development work, and the cost comes out of his budget.

[@JanVerny]

This is a different problem. Of course managers don't get, that a car with no engine is not just one quick fix away from winning a Grand Prix. But in my opinion the problem discussed in the article is that project requirements often start with describing a single-seater that can corner well. And end up with wanting a bulletproof SUV with designer cup holders. So if you go fast and deliver features quickly at the start, you're likely to lock yourself into a path that's not compatible with changes in requirements. While if more attention is given to first actually develop the product and also to write more generic future proof code, you could potentially get more done by going slow.

[@garma7939]

I do think this isa problem that is smaller in real life than you make it look though. The issue with inputting wrong characters should be handled by your forms library or at least by a standardised component that is ready to be used. Are you telling me you rewrite all that code for every input field? Adding a simple feature that uses standard components that are already in use (extra fields etc) really should be a 10 min job. The whole idea of an architecture is to make jobs like these easy.

[@KucheKlizma]

​@@garma7939Right just recycle a pre-existing standard forms library with zero research when rapidly prototyping a novel app that might be relying on a novel framework that might have entirely different escape characters and code injection vulnerabilities. That's definitely gonna allow a prototype to be shipped straight to production ready. Yes, I'm being sarcastic.

[@garma7939]

@@KucheKlizma that's not what I said. I said reuse what you already have in production. You SHOULD have a forms library in production that already takes care of those issues.

[@TheMidnightillusion]

@@garma7939 Obviously this depends on what you're making, but even if a new feature only take 10 mins to code, you still need to time to test it's working properly and not causing bottlenecks or unforseen issues with the rest of the codebase. There is a huge difference between a "proof of concept" and an actual feature that can be put into production. Going back to the car analogy, imagine if you had a car in production and your company decided to add collision sensors to the front and sides. The car already has rear detection sensors so it should be "quick and easy" to add similar sensors to the front and sides. For a prototype you probably could, but to make sure those sensors work properly in production takes a lot longer.

[@DonAlonzo]

The most permanent thing in life is a temporary solution.

[@user-jm6gp2qc8x]

That’s deep, actually.

[@alexgabriel5877]

'Nothing is so permanent as a temporary government program. (c) Milton Friedman

[@anonymousperson7536]

The entire point of the video is that this is not true.

[@Leonard0F41G]

@@anonymousperson7536 What company you work at?

[@eggmeister6641]

@@Leonard0F41G he's unemployed most likely

[@bluedevilbball4life]

Thank you, Flip. Stuff around minute 9 is what i needed today

[@flipmediaprod]

got you my man🙏

[@7heMech]

00:32 gotta love the heads up 3:44 can see it was true 😅 Added a sponsorblock segment to skip duplicated part 👍🏻

[@meatcow417]

Thanks for keeping the ad break Q&A in, those of us who spend most of our time on KZbin don't get much Q&A.

[@caedenw]

Easy analogy: you hired me to run a burger restaurant, then tried to sell to wholesale supermarkets but you still want me to cook everything

[@brentsaner]

Yak-shaving isn't bike-shedding; it's dependency task completion. e.g. "I want to do X... so I am doing A right now, because X depends on W, which depends on V, which depends on U and T, which depends on..."

[@koderkev42]

04:00 is why I don't take shortcuts. I've worked long enough to know, "it doesn't have to be perfect ... we just need something".

[@JayMaverick]

Sounds like LinkedIn fan fiction.

[@tbg07]

Bro!!!!!!! 😂😂😂😂😂😂😂😂😂😂😂😂😂😂

[@bianchialex]

*Don’t tell me what to do internet mustache man*

[@penguindrummaster]

Shout out to Flip! Bro had me in stitches at 8:35

[@flipmediaprod]

appreciate you brotha💪

[@Laz3rs]

8:58

[@penguindrummaster]

Some thing I've noticed about your videos is that you'll read an article that says "I made a mistake," and when you identify with the circumstances, you will fall back on how you viewed your outcome. If you see your outcome as a mistake, you'll agree with the author, but if you see your outcome as doing the right thing then you'll say that the author is wrong. I'm not trying to say I'm a paragon of virtue here, since self-awareness is a very hard skill to have. But I get the feeling you sometimes don't give the author their due. Presumably, they've gone through their experience, and this is their conclusion/resolution. That said, as a viewer (and a frequent one at that, lol), the thing that fascinates me in these is getting two viewpoints simultaneously. I'm not trying to tell you how to run your channel, just remarking on the style I guess. I'll probably keep watching, because, if nothing else, you read a lot of really insightful articles about the industry. At your best, you provide a really helpful insight into software engineering that even I (a senior developer) can find informative. Keep doing you, but maybe this causes you to reflect on how you approach some of these things.

[@thekwoka4707]

Them experiencing it doesn't inherently mean they got the right takeaway. But there could very easily be something left out of the narrative that made that a good takeaway. I'm most reminded of that "we migrated with prisma. never use prisma" and 80% of the things they said were serious issues with what they were trying to do and not with prisma, and the last 20% was something people sometimes complain about but nobody has yet actually demonstrated was a problem

[@the-answer-is-42]

Reminds me of the university I used to study at. I heard the IT guys say they had no idea how the system actually worked. It was a big mess and changing anything was a horror because no one understood how the different parts of the system interacted with each other. Anyway, mentioning it because it seems like the "quick patch over quick patch over quick patch ad nauseam" the article was talking about. I think we just need to adapt the speed to the project and how critical it is for business. An internal website has a completely different set of requirements than firmware for medical equipment.

[@d3stinYwOw]

About your take on power to say no/pushback. Yes, they can pushback, until some product manager comes out and says "I am pm and do as I say" ;)

[@penguindrummaster]

Saw a really good talk from NDC where the speaker suggested the idea that how we talk about technical debt is wrong (or ambiguous), and how we deal with it is more important. Specifically, he used a few quotes from articles to try and highlight a correlation, with the ultimate conclusion being that the problem is, specifically, *unmanaged* technical debt. Then, he finds inspiration for how to contend with technical debt (managed or unmanaged) from a Victorian-era housekeeper's manual. That is to say that, to keep a house (or codebase) tidy, one needs to constantly be making small strides toward the ultimate goal of cleanliness. It will never be completely clean or perfect, but the vigilance will avoid a situation of unmitigated disaster that cannot be recovered from. In short, unmanaged technical debt is the problem, and all codebases must make active strides to keep it tidy over time, or else it will become untenable over the long term and everyone is unhappy.

[@spaceowl5957]

like this. I always try to leave a piece of code less messy than I found it. If I’m already spending time understanding what it does, I might as well write a comment about the confusing bits, so it’s easier the next time I look at it. If I’m already going to have to restructure it to add a feature, might as well try to simplify and improve the structure a little bit. I cannot write super well structured code the first time around, but I continuously try to make things a bit nicer than I found them and overall I find most of my codebase pretty easy and pleasant to work with, and I feel like it’s the most practical approach for managing messiness and complications in code for me.

[@eric.p.hutchins]

Agreed I think it's a really healthy way to view tech debt since, as Prime mentioned, all code has tech debt. You never really get out of it but you can make the best of it and learn to prioritize and constantly make small improvements. And I enjoyed that Kevlin Henney talk as well. He has a nice way of focusing on how we speak as developers.

[@codegocomau]

"Uncle" Bob Martin makes this point as well: your codebase becomes an unmanageable mess because you never took the time to tidy it up as you went along. Treat it like a mechanic's workshop and you'll always know how to get started on the next job.

[@Hebruwu]

Isn’t that the principle behind LEAN?

[@CristianNazare]

6:00 no, sometimes we don't have the possibility to say anything. My manager asked me for a approx timeline for the new project frontend implementation. I told him 3 weeks - he said i have 2 weeks. Did it in 2 weeks, with me pushing extra work time from my own free time and weekends. The client was not satisfied with the implementation. Got into an argument with the manager on the amount of work and time available, and he spews out nonsense "i have a team ready to do all of it in 1 week". Eventually I was the one who fixed and did everything. Instead of the 3 weeks I initially requested the project took 2 more weeks to wrap-up (edit:still not sure if i'll be getting paid for that also). No, developers usually DON'T have a say.

[@StefanErwinBaumer]

When they cut your time, you ask them what features to cut / make a priority list so you can get as many important features done in the timeframe as possible. (there's diplomatic ways to phrase this) It is true though, that sometimes people don't give you a choice and just "force" you to fail a deadline and then make you responsible for a deadline you didn't even commit to. In this case, you should leave the company rather than work for free.

[@thewordywizard4389]

I left a company exactly because a CEO did this. Unfortunately the one with the purse strings makes the decisions

[@SourceOfViews]

I mean there is always abusive employers, but usually at least, managers will actually listen. If they don't they are shitty managers. At that point the best thing to do is probably to just leave once you can.

[@katanasteel]

If he has a team ready to do it in 1 week, call his bluff and come back in 1week when nothing works and say now it'll be 4 weeks

[@SourceOfViews]

​@@StefanErwinBaumerdon't forget: DOCUMENT the deadlines you gave vs. what your manager gave the customers. It doesn't help too much if the entire company is fucked, but at least you can prove that it's not your fault.

[@YaroslavFedevych]

I have an impression that the author of the article got burned quite badly and the suggestion he is laying out here is overcorrecting. And since the burns still hurt, the style is so rambling.

[@michaelpingleton776]

8:52 I love Flip's sense of humor 🤣

[@privacyvalued4134]

35:41 "It's extremely difficult to add a feature to a big [100,000+ LOC] codebase." Not if you architected it properly. I've written hundreds of thousands of lines of code, if not millions. I take my time figuring out my architecture/core design BEFORE writing code so I don't wind up in a situation where I can't easily add new features.

[@orterves]

The best engineers will build only what they need for the initial project spike, but in such a way that they don't paint themselves into a corner in the future

[@marceelino]

But it's still horrible tool and people are stuck with usesless product. I think devs are just full of themselves

[@kyguypi]

The assertion that you should say "oh yeah, I can't get this thing set up in time for this important deadline because it would be too messy" instead of "sure, I can get this set up before your important deadline, but I'll need some time afterward to clean it up" is wild.

[@DeveloperToast]

Inducing Scope Creep, Technical Debt, Poor Resource Allocation, and Reputational Risks 101

[@kyguypi]

@@DeveloperToast I'm not sure what you mean by this.

[@UniversityOfMassachusets]

@@kyguypihe’s probably saying to make it good or just don’t make it at all otherwise you risk the following list he commented

[@kyguypi]

@@UniversityOfMassachusets but... Y'all know you can edit code after it's written, right? You can rewrite something. In the real world, there are business pressures that sometimes require that you have to get something together right now and then clean it up later. Technical debt doesn't matter if you're unwilling to meet business needs. If you're that afraid of technical debt, you can avoid it entirely by never writing code. In the real world, I write things fast to meet real world deadlines, and tell my CEO that I will need time later to clean it up. That's way better for him then me refusing to meet the real deadline and making the business suffer for it, and then I actually take that time to rewrite the thing, which turns out way better anyway because writing code twice actually tends to produce good code.

[@austenmoore7326]

Yeah then if you get asked to add stuff onto it you can just say something like “I’ll add that but the first solution was kinda duct taped together because you needed it really quickly, so I’ll have to spend some time fixing that before I do any add ons”.

[@kuhluhOG]

8:38 I don't think they meant "low-code" as in the move to write as little code as possible and instead having it generated or the sorts, but instead as an environment where software is NOT the main money maker or really a money maker at all. Don't forget: Most software is not written by software companies, it gets created in companies on the side for some internal thing they happen to do, but either rarely see a customer or are just a really small part of the actual product the company sells.

[@GreeneThumbs]

We love you too, Flip.

[@WindosNZ]

WE DON'T SHIP ON FRIDAYS! (Unless you're Flip. Flip can do no wrong.)

[@gund_ua]

The most common issue with abstractions is "leaky abstractions" that's when they become brittle and don't really serve any purpose in the system. However a well designed abstraction will get you really far but to understand what makes a good abstraction early on requires a lot of experience - hence there is a common understanding that premature abstractions are bad, but if you will not do them or at least plan them in your head and then see what worked and what not - you will never get the intuition and skills required to do this better early in development. So do not listen to anyone and go think and design your systems and learn from your own mistakes but please don't use React - no amount of designing can help you there lol

[@AlexMax2742]

Being able to assertively push back is a skill, but it's not a skill that everyone can learn, and it's not a skill that works _for_ everyone, and it's not even a skill that works in some dysfunctional job environments.

[@DaremKurosaki]

That last part is especially true. Sometimes management can be so disconnected from reality that any disagreement is treated as heresy. If something isn't deliverable, it's your fault rather then their unrealistic expectations.

[@olbluelips]

You have to learn this at some point or you’ll be walked on your entire life

[@AlexMax2742]

​@@olbluelipsYou have to have the right personality type that can get away with it, otherwise you run the risk of coming off as a a**hole or a b**ch. I've had much better success being fluent in "soft" business language and having an "Aw, Shucks" CYOA policy.

[@duckydude20]

i feel depressed. today since morning, it went such bad. your videos, helps so much. thank you ❤

[@richardclark9535]

Good the hear Uncle Bob might be back, he's one of your top tier guests.

[@arik-mlvx]

Scotty: "Star Fleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want." Geordie: "Yeah well I told the captain I'd have this analysis done in an hour" Scotty: "How long would it really take?" Geordie: "An hour!" Scotty: "Oh you didn't tell him how long it would really take did you?!" Words of wisdom from one of TV's greatest engineers

[@meryplays8952]

I like this article. It mirrors the situation in my organization and various behaviors. I tend to push back or implement something properly. But in a society in a dire financial situation, it is harder and harder. Management many times is willing to believe everything.

[@CodyDIY]

30:50 nailed it. As a supervisor I can tell you that the people who are constantly pushing back are not given the benefit of the doubt when they inevitably mess up. Choose your battles.

[@gglegenday]

Primagen always giving hot turd takes in the first 10seconds. Amazing. Dont ever stop ❤

[@visaac]

Flip is a W editor. I love your chemistry Article was mid tho

[@Zinbhe]

I love you too, Flip

[@zdabka]

Thank you Flip!

[@TheHackysack]

love you, flip

[@tesuji-go]

The key word here is “opportunity”. When business people say this, every line of code you write for them becomes part of a new or existing product line. It’s only a demo if the demo fails to land the customer. If you succeed, you also fail. Unless you treat the code as a product.

[@williamlvea]

This is how you get to "Corporate policy mandates that all changes to production must have >80% unit, function amd e2e test coverage; must have no publicly known vulnerabilities; must publish x/y/z metrics, and must have an approved installation/rollback plan in order to be approved by the change review board"

[@Red4mber]

The hidden cost of speed is depression, anxiety, high blood pressure and tachycardia

[@Duizelig]

ohhh we are not talking about drugs? wrong type of speed i will come back when im sober

[@monad_tcp]

tech debt is great, it means we have infinite job to do. if software had no debt and could just be done. we would perhaps need 1% of the engineers we have. that's why when debt is too high you just throw away things and start again

[@msc8382]

I'm posting from an anonymous account, and you don't have to take my word for it, but I feel compelled to share my perspective. Its a long story that could have been a blog post. I'm not regretting anything though, and you've been made aware of the nature of my comment. I’ve been in software engineering for over 16 years, and there’s no platform or problem I can’t tackle-whether it’s working with embedded systems at a register level or building no-code solutions. The only real constraint I face is time. In my role as a senior software engineer, I regularly collaborate with cross-functional teams and deal with quality assurance. One recurring issue I encounter is technical debt. In my experience, both in professional environments and open-source projects, most technical debt stems from poor design decisions-specifically, action-at-a-distance problems. Blindspots of their own design. It’s not the code itself that typically causes tech debt; it’s the underlying architecture that wasn’t designed to accommodate future changes. If you build a framework without prototyping and testing it against the right criteria from the start, you’re setting yourself up for failure. Inadequate testing practices, especially the notion that tests can be an afterthought, exacerbate this issue. One example that comes to mind is to use a third party service immediately to solve a infrastructure or functional requirement, without actually testing the system first yourself against your own criteria. This disconnect between coding and maintainability (testing or refactoring) is where most developers fall short. When technical debt eventually catches up, teams go into maintenance mode, trying to patch things up by retroactively adding tests to stabilize the system. Especially if you didn't test the external services, that's when you first learn if the instabilities of such services. The real issue is that the infrastructure was never designed for self-testing. A solid engineering approach would involve building the system in a way that prevents action-at-a-distance issues from arising in the first place. Testing shouldn’t be an afterthought; it should be integrated from the beginning. Of course, if you cannot explain to your bosses why this is needed, nobody is going to pay for it. Therefore, you must already know this needs to be done, and communicate it, or all testing will automatically be an afterthought. You're being sabotaged by the very people you work for, by YOUR own design. Engineers push back when the evidence shows a choice is bad. The moment your bosses give the green signal regardless, you're absolved of any responsibility of it going wrong. But if you don't communicate, you're still responsible by proxy of your role. A developer who does not communicate, cannot really provide a stable product because you don't have the resources to do it. It requires explanations. The difference between a software engineer and a developer often boils down to understanding and applying engineering principles. Engineering involves anticipating blind spots in your design and addressing them early on. Many who call themselves "engineers" are really developers stuck in a cycle of managing tech debt because they don’t apply these principles effectively (as a team if its a team effort). Having a large amount of tech debt is often a symptom of two things: either the organization fails to define criteria properly, or individuals are too confident in their abilities and overlook the importance of engineering practices. From my experience, most developers fall into the latter category-they’re good at coding, but they don’t understand the engineering discipline needed to prevent problems before they occur. A key way to distinguish a true engineer from a developer is by how they explain their code. Engineers will tie their explanations back to core principles, showing how they’ve accounted for potential issues like action-at-a-distance. Their explanations bring clarity to even the most complex problems because they've done the hard work of analyzing and understanding the underlying system. Developers, on the other hand, often can't articulate these connections and see tech debt as an inevitable part of software development-when in reality, it’s often a sign of poor engineering. As a software engineer, thanks to developers I'll have infinite work. Software engineers actually help finish the job in a sustainable (works for 10+ years) way. If you're working on a project that is already in maintenance mode after 2 years, that's a big big red flag of a dysfunctional company. Its perfect, all the dysfunction gives me significant more time and resources to apply engineering in. After all, engineers can solve problems developers can't. That is what makes an engineer an engineer. If you can't solve ANY software problem as an engineer, you're not an engineer. Note that I'm not saying anything about the time it takes. Some problems take decades to solve, even as an engineer. But you can solve them. If you cannot tell yourself that you can solve a problem you know NOTHING of within let's say, 25 theoretical years, you're not engineer. That's my metric for it. In that timeframe, you can either proof some parts cannot be solved, or approaches can be formulated to mitigate the potential action at a distances. So what do people do who cannot apply engineering principles: They say: "Oh no, our tech debt is now so large, we can no longer properly maintain the existing features! You know what, this will cost us too much! Let's re-develop the same product, only to end up in the same scenario, many years later! Lets not at all learn from our prior mistakes!" And such, the cycle of a new major version of a product every year has come to existence. Good for fooling customers who don't even know what they're working with, horrible for business health. You're essentially: "My prices need to be high, so I can afford doing the wrong thing over and over, and not learn from it. So instead of actually improving, we'll tell everyone we've a high quality brand and up the prices of our products." I'm telling you.. at some point, marketing is the coverup of failure.

[@goodfortunetoyou]

I think the difficulty here is that if you're a single person doing something from scratch, you're going to get something very different than if you're in a massive org with top-down control over internal projects, with multiple layers of review. It's just not the same type of environment. Groups are more than one individual, and you can specialize and segment things. If you're an individual with multiple hats, you're going to bounce between things.

[@AbhayKshatriya]

Good job flip

[@agustinaguero2610]

In my company, there are a total of zero test, unittest/ab/integration...none of those, nada You could say, "thats not a big of a deal if it is a startup", the thing is, this company is 20+ years old. Things break, and we dont know why, i added logging with sentry to aliviate entering the machine and searching the logs... the cto..coulnd care less about these things..."they dont add value to the product"

[@JanVerny]

I go back n forth on this, because working in such codebase, actually trained me to be more mindful of how I make a change and also gave me confidence in my ability to reason about code, that you don't get when every single line change goes through 3000 tests and 7 step review process. On the other hand, every now and then I change 300 lines of code at once and have no idea if everything is still going to work the day after.

[@agustinaguero2610]

@@JanVerny its exacly this, cool thing to be mindfull of every piece of code, but when i migrate data/functionality, things breaks maybe 2 weeks on the line because you didnt consider a small functionality that you didnt know it even existes

[@abhinavlakhani5637]

Love you too flip!

[@max_me_is]

W Flip

[@madlep]

Oscar nomination for film editing right there.

[@AgentZeroNine1]

The Prime sounds more and more like a LinkedIn CEO as time moves on. Makes me remember that I need to force myself to read more.

[@olbluelips]

19:20 “People don’t suck at design; it’s fundamentally difficult to design well” Same thing imo

[@NostraDavid2]

Skill issue, really.

[@JanVerny]

Not the same thing. If you sucked at design that would imply that you will never get it correct. Or at best you'll get it correct by an accident. Meanwhile acknowledging that design is a difficult problem just means that people should be given more time to do it.

[@matthewp4046]

W editor

[@lucasteo5015]

opens up a project "ah what a wonderful day"

[@tomorrow6]

Searches git for #cbt

[@meatcow417]

Nice knee Flip!

[@bobbycrosby9765]

I swear by the boy scout rule. It lets you write imperfect code and code that needs to improve - code that you're constantly touching - naturally does. Code that doesn't need to improve - code you're never touching - doesn't. Oh, and you shouldn't be getting permission to do these minor code improvements. It's part of the change. If you're never refactoring old code when new features touch it you're just making everything worse, and it will be a bad tradeoff in a very short amount of time - in a matter of months. Nothing about a change request forces you to do it in the worst way possible.

[@JorgetePanete]

I get that we "shouldn't" get permission, but in my case it was enforced by the... very functional... reviewer/senior in charge saying it costs too much time and money. We couldn't do it unless it was a task.

[@defeqel6537]

33:50 I think we can ALL agree that the curly brace belongs on the next line

[@supriyomonndal6199]

Flip takes the win .

[@1234minecraft5678]

I like this Video for Flip, the BEST Internet Mustache Man Editor.

[@privacyvalued4134]

The right fights worth fighting: Legal, ethical/moral, and handling money. If someone asks you to do something that will land the company in legal trouble, say no and point out why. If someone asks you to do something unethical/immoral but not necessarily illegal, just ignore them and work on other things - usually the problem will go away on its own. If someone asks you to do something that will result in mishandling money that is a gray legal area, push back hard. You don't want to involve yourself in any of those situations and you'll save the company millions in fines and even save someone, perhaps yourself, from jail/prison. You'll be amazed how often people request such things!

[@monad_tcp]

6:11 what's the point of luring people getting accolades and getting praise if you're not going to use it later as leverage to speak for yourself and be very firm. That was a prototype, it was amazing, now lets build the real thing otherwise we might have problems.

[@anarchymatt]

YAGNI YAGNI YAGNI YAGNI WET WET WET WET KISS Dude then leaves and somebody else has to maintain all of that code

[@ov1kenobi663]

9:00 lmfao

[@Konfab]

Literally doing the POC for a project right now.

[@TheMidnightillusion]

I feel this really keenly, as I've just been brought into a new greenfield project which is looking for speed. The tech lead has chosen a tech stack that is "quick and easy" to implement without taking into account any of the requirements for the project and the larger scope. I want to stay positive but I have a gut feeling that 6 months from now the entire project is going to come crashing down around us due to this need for speed. Oh and the project owner wants an MVP out in 3 weeks when as far as I know we haven't written any code in the stack the tech lead has chosen.....

[@rafaelpereiradias2567]

9:42 sheet!

[@darkbit1001]

Arguing about a single line of code, or a variable name always brings so much frustration. I think some people just want to be difficult about things.

[@Treviath]

Hidden cost of speed: I can't read videogame hints in loading screens any more.

[@ShootingUtah]

Every manager I've ever seen has failed upwards! I've explained this before but it's the business gray man concept. People only get promoted when they're mediocre enough to not threaten their boss's position. So mid level failures get promoted!

[@JanVerny]

Impossible, I would have to be a CEO already. :D

[@cb73]

Preach it Prime Minister!

[@JohnDoe-bu3qp]

Praise is short lived.

[@JP-hr3xq]

I run a dev team. There are SIX product houses in our company who think we work exclusively for them. There are 10 product managers pushing for work to get done. I have two developers. I am not even supposed to write code at all, but I'm five projects deep while the other two are handling five between them. There is no solution because our exec said he's gonna "solve the systemic problems by hiring more management roles to increase oversight".

[@jakezepeda1267]

Every time I watch one of your vids I feel like I know absolutely nothing and wonder how I even have my job.

[@Archsage]

The Flipagen

[@avocadoarmadillo7031]

Haha the UFC Flip V Prime match: SO GOOD

[@felmora]

8:55 🤣🤣🤣🤣

[@brianm.9451]

You’re right that how business values developers is one thing. But I work for a company that decided running fast was important. So fast, in fact, we turned prototypes into production apps. What did it cost us? Developer experience. Business has no interest in refactoring tech debt.

[@nwsome]

18:44 Exactly!

[@ColinTimmins]

Flip, you’re doing great! 😂

[@TrancorWD]

Not for nothing, but given how often my interview questions about extra work load are just lies or they have no idea. I just get them to outline the "that will never happen" scenarios, because working late is going to happen. And pto is bs

[@adamhenriksson6007]

The thing is that, by NOT speaking up and simply doing your best and doing what is expected of you, you put yourself in the best position humanly possible to increase your say, power and pay. You not only still have your job by fulfilling requests without complaining or challenging opposing interests, but later on you are guaranteed to be the single most productive member of the company by far while still having a larger headcount. All developers respect you and dare not to challenge your status as top dog IT guru, else they lose their access to eldridge knowledge they need to simply do their job. No risk of conflicts that risks your reputation or pay, no risk of failed rewrites getting you fired and replaced by consultants, and so much leverage you can argue for increased equity and not even feel bad about it. There is a reason speaking up is what is missing in these discussions. Not only is it hard, but it also does not pay unless that is what is expected of you.

[@niclash]

Tech Debt == Legacy Code. Legacy Code == Code that is deployed in the wild.

[@alanonym8972]

It is funny that Stack Overflow dude considers that cleaning someone's mess is the worst part of the job. I love doing that. Just going through comically bad code, find what you were looking for (maybe with a lot of tests to make sure that you understand correctly what the code is about), making a POC for whatever your were there to do, then making the decision to either add your own bit of tech debt or fix it while you are there by adding the right tests and refactoring what you need. I love feeling the improvements of the code day by day, the constant discovery of something new, the feeling of always getting better at reading the code, debugging and understanding the domain. I love the feeling of deleting code that became useless because you just did it better, with a better understanding and a better technical and/or domain knowledge than the previous dude, or just because it was dead code to begin with. I love the constant juggling between "this is bad, but it does the job and it is not worth investing in refactoring for now", and "I spent WAYYYY too much time understanding that, I need to make it easier for the next time". I always find it more enjoyable to fix something existing rather than building something new, because I already know how useful that stuff already is. Maybe it is because I haven't seen any truly bad code yet (I am mostly a java/js/ts dev, so everything is salvageable, even years of gross negligence), maybe it is because management trusts me and knows their place when I talk about how I will approach it, maybe it is because I always give higher-than-reality estimates in order to have some clean up time, I don't know.

[@sealsharp]

I get what you mean. To me it feels like a puzzle when stuff gets ordered piece by piece and then there are moments when a few parts are decoupled enough to delete a big chunky piece it's like having a big block in tetris disappear, it's so satisfying.

[@KaranBhatt-fu2gp]

11:30 working on same situation. Manager was like “my team can do this why you can’t?” I don’t know the language I didn’t know the business requirements and I didn’t know what and where fix was needed to be make

[@JoshDix531]

IMO, if you have to have a meeting about something a goal should be to define a precedent/procedure so that you don't have to meet on it next time. If the confidence isn't there make part of the procedure be to send a notice like "hey we did this last time, gunna do it again for this new issue x". So I am open to the "meeting about it..." idea but not the "every time" part.

[@anarchymatt]

Epic editor

[@BakanoJutsu]

Updoot for antagonistic editor relationship

[@akilelamin]

Casual Flip W

[@FlanderDev]

I think i've never seen Flip edit this much before.

[@thewordywizard4389]

Evolutionary before extensible, modular before abstract

[@ScottimusPrime-j3q]

I've worked on multiple teams that really push this kind of culture. Once you push to ship something subpar in order to meet a deadline, product/execs will then set that as the base expectation moving forward. You think you're doing something good for the company by making it happen "just this one time", only to be pressured to do it over and over. Truly psychotic

[@JoeStuffzAlt]

Sometimes the management don't want things to be built properly. "We are doing these tests over and over to where if I code some integration test, 85% of the tests will go by fast." (situation is a very obvious ROI). "NO! NO TESTING!"

[@helloworlditsworld]

Prime can you do a video on what it was like running your own startup?

[@TimothyWhiteheadzm]

It is a common problem that management doesn't know what it takes to build good software. It is easy to do a quick mockup but a lot more time consuming to get a fully working product. But that is a communication problem between programmers and management and the writer seems to be solving this by changing his strategy so that management isn't confused whereas the correct solution is better communication

[@am01264]

Sounds like the story of a "beloved hero" that tripped over his own ego at some point. As a one man data wrangler & automator for my team, I find 60% of success is setting low expectations and being upfront with expected challenges. The rest is some combination of (1) writing code that does what it says on the tin (and no more); (2) assuming you will make mistakes (asserts) and reserving abstractions & infrastructure as tools of last resort. Put another way - less spaghetti mess, more tapas.

[@duckydude20]

18:59 agree, premature abstraction are same as premature optimization. 21:52 lets go e2e mentioned... 31:59 idk who said, loose small wars to win big war.

[@MaxHaydenChiz]

Re: type systems; you can *technically* prove any provable property of your code with them. But the languages designed to make this practical are either experimental (Idris) or obscure and intimately connected to a theorem prover (Galina, the Ocaml-like language inside of Coq/Rocq). How to make this stuff usable outside of the realm of "failure is absolutely unacceptable; no cost is too great" is something a lot of smart people have been and are still working on. Historically the issue was just that the overhead was about 10x. But in larger projects with lots of automation, it has come down significantly. With better tooling, it would probably be at about 50% for most use cases. *But*, you still have to have developers who can use it. And based on how lost people got when Prime tried to code Ocaml, I think we are a long way off from this stuff replacing Javascript. The underlying concepts would probably need to start being taught at the undergrad level as a first step. (How many undergrads even do basic verification with loop invariants and the like? I don't think many do.)

[@l3lackoutsMedia]

I think i was hired to add more features to a red glowing wall of erroneus typescript. Honestly the main purpose of typescript in that project was to underline all of the code with something red.

[@gruntaxeman3740]

There are ways to avoid that code-spaghetti-monster. 1. Gather us much as possible requirements and upcoming features so architecture and UI can extended to those. 2. You need one good developer to choose right architecture and tools and setup groundwork, making one simple feature so others can copy patterns from that. 3. Software design relates to organizational structure. This way you divide people into areas of responsibility. Like if some part of software is written using different language, that is logical point to reserve different people for these tasks. Adding more people doesn't help anything. Instead it is better that developers can fully focus on their area of codebase. When it is familiar, it is then more productive to work with it. Cross cutting stuff is tricky. Like premature optimization, also premature refactoring is evil. So it is not good idea to put too early stuff in src/common. Instead it is better that each developer keep their stuff in their own module, and they should not add dependencies carelessly. And when the software works, we can then refactor repeating stuff to handle all requirements in all modules. Technical debt happens but the problem is when technical debt is cross cutting everywhere instead of isolated to small part of code. So just don't add dependencies carelessly or make stuff to src/common that really doesn't cover all cases. Stuff in src/common should be something that whole organization can depend on now and something like 12 years future.

[@LionKimbro]

3:22 3:48 time loop? I thought I was imagining it, but there it is..!