The harsh reality of good software

[@awesome-coding]

Hey! That's my video! Thank you for the shoutout!

[@re.liable]

I love your videos

[@alexandrecosta2567]

are you also behind deno's channel?

[@awesome-coding]

@@alexandrecosta2567 Yes - I'm helping produce some of their videos as well.

[@futuza]

You have some great takes, awesome-coding.

[@awesome-coding]

@@futuza thanks! :)

[@unl0ck998]

Do you care how many hours someone slaved to build the desk you are using? No, and if it breaks you hate them. Its not exclusive to code.

[@mattwhite9658]

Yeah but it is more on the scale of if the entire company sat at that one desk daily. And even better the desk isn't broken the people that are sitting at it complain about the chair you didn't design or are sitting on the end of it and saying they can't see the screen well because it is 6 feet away.

[@Dom-zy1qy]

I built my desk in like 2 hours 😎

[@MrDasfried]

Just build it your self

[@t1nytim]

​@@MrDasfried that makes a lot of sense. Then when I hate myself, it'll be no different.

[@Daniel_Zhu_a6f]

software is nothing like a desk, you can't clone desks (but it takes less than a day to build one from boards). perfect cloning at near-zero cost is not something you can just wave away. it affects literally everything in the product lifecycle. in a way, it contradicts capitalism, which is built around scarcity of commodities.

[@ofadiman]

My go to language is TypeScript on a good day and Polish on average.

[@yuriy5376]

😂

[@ZombieJig]

Ironically Polish is at least 100x harder to learn than TS

[@stefanalecu9532]

​@@ZombieJigbeing a natural language with lots of exceptions and a huge vocabulary and a lot of ambiguity sure makes you harder than a programming language with defined syntax and 50 keywords at most :p

[@luisendymion9080]

LOL that caught me by surprise, good one 🤣😂

[@dannyarcher6370]

I need to meet some Poles. It may just be me but the outside impression of you lot is "lovably quirky". This comment only strengthens my impression.

[@Cyberfoxxy]

As a junior I read an article about "all code is garbage". At the time I didn't pay it much attention. I went through my programmer puberty with design patterns. Clean malleable code that somehow was future proof. Now. I'm past programmer puberty. Every abstraction I have ever written has fallen short in some way or another. There is no such thing as future proof code. The best code is the one you can quickly delete and rewrite.

[@aoeu256]

Hmm maybe, but I swear there are certain abstractions that can increase your chance of future proofing your code... Pure functions, inversion of dependencies, loose coupling, embedded DSLs, passing through keyword arguments, decorators, maybe even monads O_o.

[@taragnor]

@@aoeu256 Yeah, I definitely find you can write software in good ways and bad ways and some design patterns are much easier to upgrade. A big key I find is having code that will hopefully create errors at compile time. Things like Rust enums which force exhaustive patterns, typescript "satisfies never" in the default parts of a switch statement and similar tricks have saved me a lot of time. So that way if you ever add in a new type at some point, your compiler tells you you've missed out on handling the specific case for it. And the more your compiler can tell you and detect, the better, because you will make stupid mistakes so setting it up where the machine double checks for you is key.

[@ChrisAthanas]

Read and understand it enough to dump it and rewrite it

[@ov3rcl0cked]

Good abstractions are replaceable, which means good abstractions meet your criteria for good code. I mean I have software examples that have held up to the years and stayed maintainable, it's more so a question of whether or not people put in the effort to do the upkeep, and the more complicated the code base the more upkeep there is, but the less upkeep you do the more the complexity drains productivity. The more tech debt you create the more likely you are to just throw the baby out with the bathwater and recreate something with a better idea of what is currently needed in mind. Requirements change, and therefore so does software, you can't see the future, and eventually things might change so much that the current solution is just not going to work either. So there's still reason for good code, and there's still reason for putting the the work to keep the code base manageable, because on the flip side there's been times when we've moved quick to create software, changed it a bunch, and are stuck trying to dig ourselves out of the hole we were essentially forced to create. So yeah, everything is a balance.

[@V8Li]

There are serious issues in this industry that is at the core of modern economy. First of all you can’t write lightweight code with all the frameworks and everybody but the coders seem to have an opinion these days. Coders can take so much learning in just a few years and stay productive. There are also massive management issues with allot of people not related to coding fighting for position, even HR has been on top of coders in the past years. And there are actual business issues because nobody listens to coders, I am getting close to 20 years now and have an economics degree, I see these things and know how managers are trained. I was working for two years with an agency on a big Website (10+ countries) with all that it means (sales, CMS etc.). We never had time for scaling, they were like “this guy will have a pause in two weeks, let’s add another feature”. What do you know, sales go up in UK and wanna start selling in France. A dip in performance obviously. Before I was done explaining they should upgrade the hosting and we should start getting prepared for cloning to individual serves for each country (I had that prepared since day 1 and it was the cheapest way to scale for them) they changed management and started over with a basic Website and an external sales platform that, obviously, started two products for the two countries. This was an agency I was working with at least two managers mostly on vacation, I was not that well paid and God knows what they were charging this client. So yea, you have allot of bad things working against you on top of actual coding. Good thing is I see a shift back to vanilla at least for the Web.

[@michealkinney6205]

Lol, you really hit that nail on the head @24:15. I came into where I work and the repo was 10gb+ in size because devs before me were keeping data with the code.. I rebuilt everything from the ground up over years.. took care of the code base and developed a proper pipeline.. the repo is now

[@gorkemgenc344]

Thats great!

[@logantcooper6]

I do think in the world of enterprise LOB applications that readbility is almost more important than anything. When the technical complexity is low but the domain complexity is high, code readability is important since the code is your source of truth for how a business process ACTUALLY works.

[@justme-bobby-bee]

What's lost in Prime's take is that he is hyper-focused on 1 long function. When you talk readability, you are talking about the entire repository, a feature, a module, a function in that order in terms of importance. You can look at a long function and say "look how unreadable that is, it's so long!" as a kind of gotchya for people who say that readability doesn't exist. What is missing is the context of that long function. He skimmed right past a small function that leverages a long function and guess what, it's crystal clear what that small function does because of the lifting done by that large function.

[@Slashx92]

Real. I work on automations for business processes and the function is how money literally moves between subsidiaries, for example. And coming from the web to this job 4 years ago made me really appreciate simplicity. When implementing a single process without the need for too much reutilizarían or branching, I just write a single big function that does the thing, with maybe a couple of properly named utils functions. Having to jump through 4/5 functions with vague names between files is a nightmare when 2 years later the client wants to add a new use case. Nobody remembers what the thing actually does. Not even good documentation helps sometimes to understand code from “clean coders” (not derogatory lol)

[@AntonioDoesMetal]

This this and this. There’s a reason we haven’t migrated off of mainframes with 30+ year old code that still hold up the stock market, flight systems, and other industries. Rewriting/rebuilding would mean you would have to trust you’re not breaking 30+ years of business logic that nobody really understands

[@michaelvelik8779]

Comments that explain why something is being done. Those are a godsend a year later when you need to make a change.

[@DagarCoH]

​@@michaelvelik8779Just don't forget to update the comments alongside with it. Tests are easy to adapt, because they fail if you don't, but comments (and documentation) will just sneakily start lying to you if you are not vigilant

[@robgrainger5314]

I doubt very much that the person who wrote the Rollercoaster in Excel thought that they were using the right tool for the job. Its more like doing it because you can, not because you should.

[@Dogo.R]

The "job" was "build a rollercoster in excel", not "build a rollercoaster". It was the right tool because the tool was part of the design constraints.

[@theguy9067]

He never claimed the person thought it was the right tool, he used it simply to prove the point that you can use many tools to do a thing and if you're good with the tool, it would appear it was the right tool for the job but really it was all the developer, not the tool

[@JorgetePanete]

It's*

[@MerkieAE]

@@Dogo.Rmaybe the person who made it only knows how to build it in the excel

[@TehKarmalizer]

@@MerkieAE if the task wasn’t constrained to only use Excel, then Excel is always the wrong tool for that job. It’s a useful exercise, nonetheless.

[@locobob]

I’ve been an engineer, product manager, solutions consultant and sales manager. As soon as I stepped out of the engineering bubble I immediately got the “good enough” mindset. Once you realize that perfect code doesn’t pay the bills, and that code is only a means to an end, you get it.

[@potato9832]

The worst part is suffering the agony of peer review with fresh graduates who's heads are filled with "clean code" practices that don't work in production.

[@ZeikCallaway]

The problem I have is that if it doesn't look perfect, it looks like utter trash to me and how could anyone use the tool. I'm building otherwise.

[@Zweedish9]

I don't think we're taking about perfect code here. I think the major issue is when the product has massive architectural issues and no one except engineering cares. If you've made bad decisions about code structure or how the product is deployed and product and management don't let you go back and fix it because we always need new features, then the product could enter a death spiral. Additionally, paying down tech debt allows you to build features more quickly. I think I'm some ways, product and management can definitely be short-sighted when they adopt this good enough mentality. It's think about the next quarter rather than the quarter five years from now.

[@BryantSuiskens]

Good enough is often only good enough for today, and seldom for tomorrow. Ignoring the insistence of engineers to carry out quality control, tests and periodic refactoring sprints will doom any product meant to be worked on for longer about 3 months

[@baldpolnareff7224]

What my previous team did is exactly the reason why they're now in a very bad position, they settled for "good enough, it works" and now they have a huge but fragile infrastructure they can't maintain nor change without a massive refactor

[@BobBeatski71]

I'm a HW guy. Have taken on a Java project that ultimately ends up as a piece of hardware from the code output. To learn Java, I bought Java beginners by Oracle two years ago. Yesterday was the first ever JUnit for the project in its 8yr life! I've had to do this because each new HW product starts as a new J package, with existing code copied / pasted / tweaked by overrides. It's an enormous intertwined f'in mess that now does not work unless one knows all the gotchas. When I mentioned this to one of the original coders, his reply was "it was good enough to get the job done". That guy has a PHD and insists on being called Dr. I call him Mr to bring him down to earth.

[@baldpolnareff7224]

@@BobBeatski71 I worked at a hardware company myself, manufacturing always takes priority over code, and requirements are never clear, it's just not a good experience. Hell, the IT infrastructure sucks in these companies in general, you can't always develop software under normal conditions. So I see why people settle down in a sense, these companies never prioritize good software. But nonetheless, it should be a priority

[@hamm8934]

Exactly this. Whenever people say “just get it working”, all i hear are people playing not to lose, instead of playing to win. “By the time you need to refactor the code, youve already won because your product took off.” Yeah, until it dies a month later, ie the current state of the gaming industry and nearly every website. The fact of the matter is: you need to “just get it working”, in the present sense, and the future sense. Otherwise, youre not playing to win.

[@ame7165]

my last company did this. "let's use stored procedures because they're easy". literally thousands of stored procs later, upper management says let's move away from oracle due to cost. cool, who wants to rewrite thousands of procedures from oracle flavor to another? nobody? not to mention the troubleshooting hell when you're using debugger and then reach a stored procedure call. everyone dances with joy at this point yes? no? 😂

[@airman122469]

This is the state of the software I work on. I tried multiple times to get them to halt and rethink, but nope. They just pressed on, running on that feature treadmill. And now it’s all unmaintainable garbage that I honestly can’t stand to look at.

[@luizpbraga]

the manager is also the HR of my company. I can't complain about him to him. :(

[@microcolonel]

Somehow way worse than not having HR at all.

[@conorx3]

HR works for the company not for the employees

[@brunopena3710]

You can do it, but only once

[@microcolonel]

@@conorx3 sometimes your incentives are aligned, which is when it works out.

[@BoominGame]

Bit like the Police...

[@judedavis92]

Hot take: software is hard and complex. Your job is to make it simple and build on the simplicity.

[@yuriy5376]

Is that even possible? How can you build simple software for complex business requirements?

[@Kwazzaaap]

People say this and then pack a bunch of complex logic behind some weird type or function and suddenly you have no control and are locked in some pattern that cannot possibly be best for all the cases its marketed for

[@MrSanchezHD]

@@yuriy5376 By using the right complexity management technique for the job. Something learnt through experience & research.

[@judedavis92]

@@yuriy5376 make it as simple as possible. As the software requirements become more complex, then build on these simple constructs into more manageable solutions. That’s how software must be designed. That’s where I think things like DDD _could_ be useful.

[@thewiirocks]

Our job is not just to make it simple. Our job is to take incredibly hard problems and make them look effortless. “Effortless” software is so slick and easy to use that it seems from the user’s perspective that it must have been easy to make. …which sadly then leads to bad management killing off top performing teams because they just spent the last year “rescuing” a shitty team and believe that their “newly improved” team can clearly do such a simple thing better than the pathetic team that’s currently managing it. 🤦‍♂️

[@SuperPranx]

Just because a famous framework has non-readable code, doesn’t mean readable code is bad. On a big, long term project where new people will keep coming in, it’s far more important to make code easily readable. If each function states clearly what it’s doing, reading code is similar to reading a story about what that code is doing.

[@edipedipbulmaz]

exactly! i LOVED to go through some python scripts. they feel like a long ride.

[@Tony-dp1rl]

The best written code is the code that is easy to replace ... almost every good pattern or practice stems from that.

[@ChrisBensler]

I agree that experience in many ways makes software dev more difficult. I was at peak productivity/effectiveness when I was still naïve of all the best practices. It is commonly understood that 'cowboy' coding is a bad thing but in over 30 years of doing software dev and programming, it is usually the optimal strategy. Fancy tools, methodologies and paradigms are massive technical debt. Good devs know how to KISS. The vast majority of the time, good code does not mean making bulletproof code, it means making it as simple as possible without painting yourself into a corner.

[@someguyO2W]

I've been thinking about this recently quite a lot.

[@TehKarmalizer]

It’s all going to be technical debt anyway.

[@retryhikaru184]

its a good approach to anything in general. You just learn over time, that people just don't give a sh*t and everybody has agenda, so why bother go extra miles anyway. Just survive and do the minimum and you're good.

[@chauchau0825]

Sinplicity is key but never easy. Saddest part is that not-so-good devs write complicated code thinking what they did is "simple" or "clean"

[@Rick104547]

What I find hard is getting the rest of the devs on board though. So many devs practice dogmatic clean architecture for instance thinking it's the way. Takes alot of time and energy to change that around.

[@md2perpe]

My goto languages are BASIC and C/C++. There are not many other languages having GOTO nowadays.

[@Octogenico]

Lua :)

[@infeltk]

SQL

[@tole3590]

Bruh 😂

[@danvasicek4122]

Good joke saving this one also Batch scripts have goto iirc

[@paper_cut9457]

there's shitty code and then there's the data analyst code. that's one of the most amazing mess

[@Ryan-qu4vx]

Very hurtful, 100% true but still hurtful.

[@paper_cut9457]

did not mean to hurt anyone. apologies. I'm an analyst myself and I'm just amazed at how things keep working in offices like mine.

[@smort123]

Instructions unclear. Put all my production code in a Jupýter Notebook.

[@Ryan-qu4vx]

@@paper_cut9457 Obviously no offence taken. I'm an analyst as well and I've seen the disaster code firsthand. I like to call it Buca di Beppo code because that spaghetti code is family style.

[@haroldcruz8550]

damn

[@hardcorecode]

I have a simple rule. code complexity should match the bussines requirement complexity. I naively started a side project that I thought was simple three years later no matter how much I refactored my code it's just complex. I learned from this that there is no such thing as a simple "real world" software. if you software is simple it has "no value" and no different from the many software projects I completed as a cs student.

[@thewiirocks]

If you haven’t read The Mythical Man Month, you might enjoy it. Brooks spent a good chunk of the book talking about inherent complexity (the complexity needed by the problem) versus accidental complexity (the complexity caused by the methods used to solve the problem).

[@genechristiansomoza4931]

Try creating accounting software. It's a simple +- right 🤔

[@akovaski]

19:10 This is something I believe is a good way to fight bad abstraction. For me, I've been phrasing it as "The correctness of the code should be locally obvious." This is something I started thinking about when I had to dig down many branching levels to see what a function did, then I had to do a scan of the project to see how an object was initialized, so that I can know which class to further dig down to see what function was actually being called on the object, which again required tracking down the various ways object's members were set. There are 2 paths that I know of to fulfilling this guideline: make the code local or make the abstractions robust. Good libraries are an example of robust abstractions, where you can reason about your program without having to read the library's source code. Though even if your abstraction is robust, someone who reads the code will probably need to learn your abstraction to verify correctness, so making the code local is generally a strong choice. (Re-listening to the clip, "you don't have to learn new abstractions" is mentioned, so I like double agree with this guy.)

[@Shogoeu]

Am I the only one that rediscovers my own code every 3 months and after I read how it works, I'm amazed how flexible and maintainable it is?

[@kakwa]

Well, the 3 months figure is worrying. Personally, I always throw-up seeing the code I've written in the past. But in most cases, I only have to rediscover it every 2 to 3 years generally.

[@justinlynch6691]

Why worrying? If you're not touching your code for 2-3 years are you iterating?

[@anyonei1806]

Yes, sometimes it's a pleasant surprise. I find that mapping coding abstraction to business abstraction increases the likelihood of this happening as the business requirement changes in ways that the code base already anticipated.

[@petersmythe6462]

"the person who works on it can continue to work on it." What if a different person has to start working on it? What if they quit? What if the project needs more developers to scale it up? What if they demand double the salary and a stake in the company for half the hours or they'll leave? What if they take months off for maternity leave? Is it gonna be a black box until they come back? When they do, are they even going to remember how their own code works? Part of the problem with bad code is that when anyone else needs to work on it, it becomes an intractable problem. This isn't to say you need to turn everything into maximally encapsulated OO, or 10-line highly nested do nothing manager functions, or increasingly nonsensical inheritance trees, or for that matter stateless functional code. What it does mean though is that someone else should be able to read your code and be able to figure out how to change it without understanding how every line of the codebase is coupled to every other.

[@Tidbit0123]

I love what youre speaking about in the beginning, I am currently developing a feature at work and everything is new, I am a graduate dev trying to implement a masstransit feature and its honestly fun tbh, but productivity is slow because I am a) googling everything, b) trying to write good unit tests c) message queues are hard to debug haha. But tbh I think I am nearing the end and its awesome, feel like I have personally learned a lot, but I feel slow, too.

[@digitalspecter]

I've been a dev for 30 years, it's one of my hobbies as well. I've been trying to get better every day but I still feel average. Why? Because of the complexity of multiple conflicting goals. I very, very rarely get to feel like "this is the best solution" because everything is a compromise. I think there are better and worse compromises but most of the time what I feel is a slight disappointment. Also, it doesn't help that every OS, every programming language and every API is also a bunch of more of less annoying compromises. I wish computer science was more of a science but also that the industry cared a bit more about what the studies indicate. One corner of the industry is busy reinventing the broken javascript wheel every couple of weeks and the other corner is bolting more crap on Java.. but we're not ready for any kind of paradigm shift because most people don't want to learn new things and like Prime said the "best tool for the job" is just the language&framework one is the most comfortable with.

[@tomtech1537]

I think coding in industry is far more of an art than a science, which is why no one can say what is 'good'

[@DingleFlop]

The NP + NL situation, to me, is actually what ChatGPT is PERFECT for. It allows you to explore a new problem, and relate that problem to a language to already know. ChatGPT is not good for 90% of the things people think it is, but as an interactive learning tool, it does GREAT! It can't teach you fundamentals, but it helps you more broadly apply the fundamentals you already know.

[@DingleFlop]

Someone in chat said "Clean code is opinionated" I'd say "Opinionated code is good code" PARTICULARLY because it's "led" by a person, rather than an amorphous blob of principles, patterns and expectations that aren't very cohesive.

[@rothn2]

Preemptively adding abstraction is usually a bad idea. Add it when you need it!

[@DarrenJohn10X]

Classes are abstraction. Java forces classes on you even just for Hello World. No wonder so many hate Java.

[@dannyarcher6370]

@@DarrenJohn10XDon't blame OOP for Java's failures. C# is amazing.

[@ben_clifford]

19:10 I agree with your friend, and I've been saying this for years. We've known for years that readability matters. If functions are too short, readability suffers. But when a logical block takes 2 page scrolls, that's also unreadable. Trade-offs, people.

[@AnatolKukula]

At 16:20 tiny pieces are brilliant. Like Lego pieces vs puzzle pieces. Puzzle piece can fit only in one place, Lego pieces can be rearranged and reused. If I am not mistaken that's a part of Composition over inheritance

[@kennethhughmusic]

25 years in the industry and the main thing that goes through my mind when writing software is "will someone else be able to maintain this without wanting to end their career as a software developer". If you write code that no one else can maintain, expect to maintain that code for a long time :) I agree with the "readability" points though, in fact, I agree with the majority of what you said around the state of code and I have added to the mess LOL I also maintain that the more generic something becomes, the less useful it is. Some real gems in here

[@N5O1]

19:01 this is exact reson of this recommendation. Because you divide your 200 line function in 5 smoller ones, with names that explain what this part does, and if you have static types it even better, because you can see what set of data you need to pass there and what it returns

[@PiratePawsLive]

Thanks Prime for your incessant hammering on not abstracting. I'm currently writing new docker containers and systems for our cloud at work and started to abstract. Then remembered your yelling about it. I killed the whole project and restarted from scratch, no abstraction, just simple neat sequential code. And am thankful I did :). You are right, experienced programmers really got an abstraction problem (me included, been writing code around 15 years now). Good fortunes to you good sir o7

[@benjikrafter]

I'm so glad my manager owns the tiny company he does. I never have to worry about being told what to do by 10 steps up the corporate ladder. And it's such a small team that my voice is important. I'm able to code my best, be comfortable, and have positive motivation. The reality of most people's software engineering jobs is terrifying to me. And hopefully I never have to understand that experience myself.

[@johntoniolo46]

Back in my algorithms class in college I learned about overdoing the concept of very small functions / large abstraction chains in an unexpected way, and the lesson keeps revealing itself in new ways. Mergesort... You simply break the array into two parts, merge sort each of them, then merge them together. This is great when the array is 1000000 elements, and 500000, and 250000, and so on. It's not so good when the array length is 16 due to the overhead of the recursive calls and that dividing something by two gets you fewer and fewer shaved off elements each time. Indeed, once you get below a magic threshold of about 16 or 32, it becomes more efficient to simply insertion sort instead of continuing to subdivide... To "just do the thing" instead of offloading it to more and more subdivisions. Though this is performance vs code style, I think it provides some intuition that some abstraction is good and necessary... Merge sort is more efficient than insertion sort. But you can overdo it. A 1000 line function is probably bad, but a 100 line function might be as small as it makes sense to be. Breaking it up further would just waste not only the developers time, but the readers time jumping from useless function to useless function. I think this goes for many concepts not only in computer science but in life. TLDR; Diminishing returns, use common sense over dogma.

[@OurSpaceshipEarth]

250,000 or 32 just use the same logic. thre's no way 32 will take more time then something with ~7,500x elements/iterations

[@tole3590]

Bro cooked but no one was hungry

[@0x0404]

Good to see different takes that still align overall. From somewhere else I'd taken "Write code that someone else can understand 6 months from now". That someone usually being yourself.

[@porky1118]

4:15 Whenever I learn a new language or tool inside a language (like ECS or a game engine), I usually try to replicate something I've done many times before, like reprogramming ball physics and connections like in World of Goo, or trying to implement compile time dimension generic geometric algebra.

[@mateusleon]

24:35 living right now, and is so true. When I started 16 years ago, I was taught that the most important duty in programming was keeping a good eye on the code you needed to maintain, consistent tabbing, etc, and nobody on my career was careful enough to keep the codebase nice and clean.

[@02052645]

Joke's on you, I knew my code was shitty when I wrote it.

[@simpeers]

Small Focused Functions is bliss. But I might be biased as I prefer functional programming, and thus it makes perfect sense. But then what the point of that is that the functions does one think, and it should be quite obvious what when you just read its name.

[@lelilimon]

15:38 I like how he sits so still while being almost swallowed

[@mroliveoil]

xD

[@kerryb3798]

We use around 20-40 msg functions to read from a mbs server. I rebuilt it to read the entire database with one msg using sequencing. It does the same thing, but WAY more advance and FASTER than I'd ever thought in my previous years.

[@mbrofoc]

Good job, but sadly only you will remember it

[@marloelefant7500]

Really agree with you on the function length. I once worked on a code base with hundreds of one-time functions, many just calling other functions, and often badly named. It was so hard to track the control flow without a debugger and even with it required infinite working memory in your head. I definitely do prefer well-structured long functions over a multitude of small functions.

[@daxeckenberg]

4:46 How about working on the logistics of a product ( SRE before SRE: plumbing, instrumentation, tooling, etc) only to have the product launch cancelled two weeks before public beta. Even better, ( which most people can't believe ) agreeing 100% with management that although the product would be successful, it would distract from a sudden and rapid change in the competitive landscape. "Hey Ted, just an FYI and you didn't hear this from me.... Jeff Co. are signing revenue share agreements with the big 6 for variois thin round pieces of plastic. " Option A: spend marketing $$$ launching a UK service ( first intl expansion ) as planned for the past 18 months. Option B: Cancel above project and pour $$$ into price cuts, domestic improvements to keep Jeff Co. from entering into an easily profitable enterprise given their existing large primo user base. Obtion A would have been validating for all the blood sweat and tears... but selfish upon reflection. Option B helped keep Jeff Co. at bay.

[@jeffwhite3867]

"Clean" code can also just mean no old/unused code commented out nearby, no overly verbose clunky implementation when a simpler line of code will do, no obvious code smells, no hacky solutions, no shortcuts in the language that could potentially cause problems later, no lines that go 1000 characters to the right, etc. I can't stand it when people automatically assume Clean means that one book that nobody likes. Clean as opposed to dirty, not clean as opposed to [insert your preferred paradigm here].

[@brentlio5578]

Atomic pieces: Regex to scan important instructions/data from robot code. Small features: Robot motion point joint knuckle flipper, code formatting, comment injection, various data extractor from running robot programs, setup validation tool, etc. Everything together: General robot commissioning tool.

[@AK-vx4dy]

Maybe aversion to small functions and hopping is line between VIM and IDE? Becuase most of IDEs greatly improve this hoping experience. Also meaningful names limit necessary hopping too. Anway i saw once owner of the firm who have and trains x20 programmers and he opted even for two line functions but he also admitted that they select specific type of people to his teams

[@_skyyskater]

Even the best programmers will occasionally write some pretty hard-to-read code. There is often a sliding scale/trade off between efficiency and code readability. Also other constraints may come into play. I do believe most code can probably be improved by an order of magnitude in terms of readability, but this is due to a lack of training and industry standardization in this area.

[@Ekitchi0]

Small functions make the individual functions easier to understand but you kick the can down the road because it can easily make the larger function using all the small ones harder to understand. I think the priority is if a functionality can or needs to be reused many times, then it should be its own function. If you split your large function into smaller ones that are only used within that one function then it was useless to split it from the start.

[@jordanjackson6151]

2:55. Lua! Everything else for me is a purpose language. Lua is like my hobbyist language (But I LOVE [2D] it the most). Everything else is: Python, C++ and Assembly.

[@KazmirRunik]

5:03 My way around this is to just lean into it. When something is bullcrap, I agree that it's bullcrap and want it to change. It frustrates me, too, and I should express that. It not only helps user morale, but sharing in the frustration of people working under me also helps with morale, because they also don't want to be unheard.

[@chrisstadler7111]

I couldn’t agree more with your assessment of how to stay happy with your development journey

[@raph151515]

if you don't feel doubts while writing, it's probably going to be bad. Whatever your current level, you should be aiming at least slightly higher. It's not about how many design pattern you can cram into your code but the overall coding efficiency, code simplicity and performance. It's about looking for new angles. Let's take the example of the APIs of the modules (JS) you can refactor them for an eternity and still find better ways. How to be concise, performant, readable, how quick people will use what you created and how good the result will be for them.

[@shapesinaframe]

7:03 unfortunately “good enough” has to be the way because there’s always “just one more thing” that could improve things. I’ve lost count of how many devs I’ve seen go down rabbit holes gold plating a solution blowing out budgets beyond belief which only reinforces the “good enough” approach

[@ferinzz]

Never forget : Support wants to know where they can poke to know why things aren't working right. Meaningful errors, tools to fix things without dev involvement, understanding what aspect relies on what system at a high level. How can we show where something isn't working so you can go straight to the issue.

[@TheJacrespo]

We need to escape from our code fetishism and see things from the other side of the business to realize that if you don't know the in-depth and minute nuances of the domain you are trying to model with your software, your software will result in accumulating overengineered, convoluted designs and features that don't bring any value, advantage, or profitable innovation. That is what the people who are paying/investing need. So, we have to be good at two things: coding as a means but attached to business-relevant goals. DON'T CONFUSE business goals with features. This is the fatal error that most of us in hardware and software engineering have committed in the past.

[@brinckau]

We rather need to escape from our commodity fetishism. - Do you like coding? - Oh yes, so many business opportunities. - What do you mean? - I created my company last year. - Ok, but what about coding? What type of software do you make? - I make software with tremendous profitability. I'm sure my company will double its revenue this year. - What's your favorite language? - $$$$$$$$$$$$$$$$$$$$$$$$$$$$ - Do you have some advice for a beginner developer like me? - Yes, you really need to see things from the other side of the business. Think marketing, human resources, market research, balance sheet, assets, merchandise, shareholder, industry, sales, innovation, efficiency, productivity, business model, management, cash flow, market segmentation, customer loyalty, distribution, logistics, expansion, competition, branding. - ???

[@vargonian]

I am a fan of the smaller functions, and then creating new classes if you have a giant class with a bunch of little functions. It makes it so much easier to change/fix an issue in just one place. I am not a fan of the term “self-documenting code” for the same reason that Prime isn’t a fan of the term “clean code”. This is also why I don’t dislike comments as much as other people; they help me more often than they confuse me.

[@BrentMalice]

the no googlin thing is so tru. i switched to linux cuz of prime and broke my pc 4 times with internet, 5th time i didnt. not being able to Bing Copilot and copypaste made everything fun i miss windows

[@mykytapolchanov6490]

It is impossible to break NixOS tho.

[@theodorealenas3171]

I still remember when Windows was my caretaker whenever I would bork Linux and feel bad

[@pluto8404]

I dont miss windows ads. Basically puts you center in time square while you just want to look at some funny cat jifs.

[@BrentMalice]

im deff not missing it. so far every game i wanted to work, works (league/dota/battlebit/wowclassic) and vscode and even GIMP open just... instantly. idk how this is even possible. this whole symlink thing is pretty daggon neat too. and search is instant, cloudflare warp just works... second time ive tried linux and first time able to stick with it, all thanks to bing copilot being so good at answering everything. only thing i hate so far is the default nautilus skin but i havent tried changing yet.

[@theairaccumulator7144]

​@@pluto8404you can easily disable all the bloat ware except the MS store

[@nijolas.wilson]

I could talk forever on this topic, but the short version is I firmly believe the only candidate for an objective measure of "good" code beyond it simply working is properly tested code.

[@Heater-v1.0.0]

I don't understand your logic there. I mean one has no idea if ones software actually works unless one has tested it, at least to some degree. The degree to which one tests it shows how much you care are about it actually working. Unless you are happy to let your users test your creations.

[@someguyO2W]

What's your objective measure of "properly" tested code?

[@theodorealenas3171]

100%. My teammates hate me when I say this but I only trust bits of code that executed recently.

[@newjdm]

19:50 Fair point. For most PR’s I have to use IntelliJ’s review feature and hop around in the code to really understand the logic

[@ijchua]

Always remember HR is never on your side. They are always on the company's side.

[@balijosu]

Yes! They are not "resources for humans", they are "human-shaped resources" for the company to use.

[@trushbetold]

If you're not on your companies team, it's because your success is not tied to the companies success. It probably means you should be looking for another job

[@martinkrauser4029]

The only time that is true is when you own the company. Every other case means that your making more money comes at the expense of company profit, because profit is what you create minus what you get paid.

[@trietang2304]

I generally break into function when I think a block of code is so complex that I may forget what it does in the future.

[@Kane0123]

So long as the .exe is named well, I’m happy.

[@marloelefant7500]

When starting a project, I usually start with a single file, implement everything in the main, until I start to notice patterns or it gets complicated, and abstract from it. That way, I progressively abstract and when it's done, I have a exactly as many abstractions I need.

[@SandraWantsCoke]

18:55 - (5) is not necessary if you start with atomic components and use them everywhere. It's the opposite of first writing a bunch of spaghetti and then trying to find similarities in random patterns and abstracting those. (done that unfortunately, but gotta learn somewhere).

[@mentalisttraceur]

I am a huge proponent of what you called "eyeshot development" here. I've been using the word "locality" for the idea, but "within eyeshot" is really nice in how plain and not-abstract it is. Opposite of "spooky action at a distance". If I change code waaaayyy over there somewhere, and it breaks this code over here, that's a non-local change/effect. If some function in that other source file mutates this data that's being used by code I'm looking at here, ditto. Low/poor locality of stuff that's related and coupled. Ideally we'd make proximity/locality correlate to relevance/coupling. If I need to read/see both anyway, maximize locality, get them close to each other. It's obviously not supposed to be an "infinitely strong" rule - it doesn't always outweigh everything else. All best practices are weights that pull one way or another, better code is better balance of those pulls. And locality/eyeshot is definitely one of the pulls. Our life is better when all *relevant* information is as close by as possible. Same file, same screen. Do we need to know *that* code to understand/verify/change *this* code? Then it should be nearby.

[@davidlamb1107]

You're not supposed to be changing the kind of code that would have that sort of effect, though. Such changes should be breaking the contract, and you shouldn't be breaking contracts that are already in place.

[@retakenroots]

As a junior I was eager to start coding and solve problems because that is what we are taught to do. Through experience you become a senior and then you become afraid to start coding because you know you will fuck-up eventually. 🙂

[@terribletheo8401]

Congrats on 600 videos

[@zwanz0r]

"You should have 3 goto languages". I've got HTML, CSS and JavaScript. Glad I made the cut, thanks 🙏🏻

[@personalaccount1515]

Gosh! Dude are you on fire in this video. Wonderful! Clap, clap, clap

[@fischi9129]

honestly, the good enaugh approach is probably the #1 reason that I go into a burnout. I want to make a feature as complete and good as I can, and then pretty much keep my signature below that, but the reality is that deadline make me take the good enaugh approach, and I'm never satisfied with the outcome of it. For instance, on my personal projects, if I do something, I'll work on it till I get 0 warnings and 0 errors as much as I can until I move on, professionally, whatever man, it's a pointless warning, it works perfectly anywhays

[@bepamungkas]

Dont focus too much on your code. Focus on your domain instead. If your code able to reflect your domain problem, then it's not merely "good enough"; its "working as intended". More often than not, programmers got dejected because they failed to conform to their domain and strictly look at problems from technical perspective. A good example is how programmers (usually) see POS software like its some kind of STD. Despite being perfectly suited for its intended use.

[@fischi9129]

@@bepamungkas Idk what POS software means, that being said, I think my problem is, I want to make the best out of the tools I have. This means, If I can make it with 1/3 of the compute time, I want to do it with 1/3 the compute time. If I can make it with 0 warnings and errors, I want to make it with 0 warning and errors. And if I can have 0 hacky things in my app without giving up 2 months, I wanna do that. But more often than not, hacky solution takes 1/50th of the time, and is therefore the prefered choiche by comopanies

[@bepamungkas]

@@fischi9129 point of sales a.k.a cashier and backoffice app, but sometimes its jokingly refer to other "POS" meaning, since its domain heavy and quite unwieldy to develop and maintain. As for tempering the perfectionist desire, if you have the appetite and time, best to do it on your personal projects. Since on the job, the value of our code is tied to the business as a whole. And usually we have little to no control over it.

[@errrzarrr]

The name of the decease you are talking about is Scrum

[@ritwikyadav9749]

At the end of the day just enjoy what you are doing. If you can find a way to not look at a problem as inconvenient but as an oppurtunity to learn and get better your life will significantly be better despite not actually being better in any objective way. It will be the same thing but you will get much more joy from doing it just because you believe it to be fun/interesting learning project.

[@tubebrocoli]

The thing about abstraction, is that to get the "right" one, it needs to be canonical, and there's no easy way to know what that is, and the language you're working in may not even support it natively. (and if it's not supported natively, it won't be canonical). The only way to get to those is with tons of experience with the specific problem, or with maths, and most programmers can't tackle the same problem enough times, and most programmers also really struggle with pure maths thinking.

[@colinmaharaj]

Yeah I'm good at tcp programming and use the Indy framework in C++ Builder

[@stefanalecu9532]

I'm using Indy framework but in Delphi, hello :p

[@carljacobs1287]

After using Delphi for 20+ years, I still enjoy it. I don't care if it's outdated, it works for me.

[@jaceklanger7735]

The idea behind small functions sis not to extract every block into its own functions but to identify varient and invariant behaviours and creae more generic behaviors, so that you end up with less. There is no hard limit on how many lines a function should have, but there is a good chance that you can write more generic code when it exceeds a certain length, as the generalization often stems from actually following the DRY principle rather than clean. That being said a generic function can be hard to read at times.

[@susiebaka3388]

19:40 considering you use Golang now and you can so easily import packages from remote sources, do you think your opinion will change on this?

[@anonymous49125]

choosing the best tool for the job means, you know a lot of languages and you choose an appropriate language for the task at hand. "Is it going to live in the clientside browser?" if that answer is yes, then you really are limited in which languages fit the bill... "are you going to need access to local files and system information?" then it would be a whole different list of possible languages you can use. However, usually if you have someone that knows very little and only one or two languages, they will just choose from what they know and try and 'force it' to fit. I remember writing a web scraper in batch for work once because the boss just knew batch and nothing else.... you would be shocked what kind of crazy stuff you can make with the worst language for the job.

[@TatianaRacheva]

KZbin has recommended this person to me before, and I didn’t realize he was a software engineer. He has a very interesting video about why insects are drawn to light and why they circle it.

[@cds5506]

I mostly build for the web so I use TypeScript and Go for the most part and it lets me solve most web-related problems.

[@FlanPoirot]

the web is boring, how many times are you just gonna do CRUD before you get bored? it's ok if that's your job, but there's much more to programming then just storing and presenting data on a web page (which is hands down one of the most needlessly overengineered areas of IT if not tech as a whole

[@anoh2689]

​@@FlanPoirotI am curious. what are the other programming domains that are better than the web in your opinion?

[@dputra]

​@@FlanPoirotnot all web is equal

[@FlanPoirot]

@@anoh2689 not "better" as making websites is obviously useful, without the web access to information would still be limited and there's great value in it. but limiting urself to just web development to me seems like deciding to be a carpenter that exclusively only makes chairs and refuses to make anything else, it doesn't make sense. I'd say just explore what programming has to offer, do ur job as a backend/frontend/whatever u need to do to get paid, but it never hurts to do more. as for other areas u might explore: low level programming, emulation, CLI, encryption, graphics, databases, ML, GUI, embedded, compilers, simulation, data science, etc. I mean, the great thing about programming is how versatile it is, u can provide (real) value by doing a lot of things with it and adjacent knowledge in other things that might also interest u

[@mattymattffs]

Don't abstract until you need to abstract. It's that easy. If it's not an api, it doesn't matter. Abstracting it later is easy. On the other hand, don't abstract minutia. If there are three similar processes, but they're too different for a general abstraction, just don't. Copy and paste is fine here. Don't over confuse.

[@tordjarv3802]

My defenition of good software is "if I don't feel a strong urge to throw my computer out of the window, then it is good software". Thankfully, my will to not get broke is stronger than that urge.

[@jon9103]

HR has its uses but it's important to keep in mind their job is to protect the company, even if that means screwing over employees. That doesn't mean they won't help employees because often that is mutually beneficial to the company but make no mistake they are NOT your friend.

[@mateusleon]

12:17 the look that he makes, staring at everybodys eyes, is really absourd.

[@lucastperez]

I remember finding your channel a few years ago when I started learning vim and wanted to write my own vimrc and also to get better at it. At some point I just stopped watching your videos. I don't really have a reason for that, I just think that I wasn't interest in rust or other things you were doing, or the memes, don't really know. But I really like these videos like this one. It is a talk about software, it makes sense independently of the language you use the most, it is just honest takes on development process. I love it. Contratulations on the content 👏

[@kebien6020]

7:41 60% percent of the time it f*cks you every time

[@piotrjaga6929]

14:30 this sounds like "every turing complete system can compute everything, except whether the algorithm will compute something in finite time"

[@mks-h]

I'm not sure if this holds. Speaking about very literal measurements, if it computes in finite time - we will know it, if we don't - it may or may not. But that's more of a lifetime limitation, rather than machine's.

[@piotrjaga6929]

Yes you are right, i didnt put it into right words but the idea is there@@mks-h

[@arcan0n123]

My mom thinks my typescript react app is clean code. Everyone knows popular things are the best which is why i take my dates to McDonalds.

[@pluto8404]

popular = average. Also, take her to the taco bell that is closest to your house, so when she has to explosively evacuate her bowels, you can take her to your place which is strategically closer, now she is in your home, alone with you.

[@tttm99]

A shopping list is handy. Disposable. Concrete. If you can generate it quickly, and the cost of rewrite can be kept low, why write a perfect abstract shopping list you have to adaptively decrypt every trip? - adapt to every possible period? - category of item? The epiphany waiting for most new developers is your code is a shopping list. It's rare you will get to a stage where a generative recomposition from smaller components can't be faster than perfect up-front design and abstraction. And so often then you're immortal code will still only be harder to replaced, it may not even need to have lasted the duration of creation.

[@JamesTDG]

10:35 I believe that readable code is moreso a game of simplicity, so that people can easily reverse engineer your work and apply it to their own projects

[@pavelperina7629]

I believe in a clean code - as long as project is completely isolated low level code without dependencies or small application. Let's say up to 20 files and higher tens of kilobytes. Once it has like 3 layers of abstrations (and it's hard to even find all methods that class actually has), many classes that are glueing together simpler classes add logic of their interaction, interractions with gui, error reporting, it get's complicated. And then add serialization and undo stack.

[@mentalisttraceur]

About "readable" - the problem is that readability has subjective and objective components, and many of the objective components are relativistic rather than absolute. So yes, there are objective readability factors: human vision has mechanical and computational constraints which can be studied, understood, and optimized for (this is why newspapers and textbooks use thin columns - it optimizes for less eye saccades, and this is one of the reasons why line width in code is partly an objective readability matter). Of course, there can be physical and mental variations between people that make us more sensitive to these objective factors, so it's partly absolute and partly relativistic. There's also stuff that seems "subjective" only because it's heavily relativistic. For example, whether you find camelCase more readable than snake_case is heavily influenced by what you're used to looking at, so that can feel like purely a matter of taste when part of it is *habitualization* - and we can measure this in our own lives if we ever spend enough time away from one style of naming, and then see how we feel when we come back to it. (For example, I used to think camelCase was equally readable to snake_case, but then I noticed that even though I was instantly comfortable reading snake_case after years of programming professionally in camelCase, after a mere two-three months doing snake_case full-time I found camelCase harder to read.)

[@imerence6290]

One of my favourite features of Google's Gemini is summerizing his long ass videos.

[@g3mint446]

Sometimes I wonder if uncle Bob tried a big project using small functions? I've tried writing clean code for so long. One big project I refactored over 5 times trying to get it clean, on my own time.. No pattern was suitable and I ended up with a bunch of abstractions for business logic that just didn't belong there. One large well procedurally written controller function was the cleanest it could ever get. Anything else was a complete mess to work with. The cleanest code I can write for applications with no UI often boils down to a large controller, some utility functions and well fitting models for objects that should be objects. Anything else makes it just harder to work with, and is absolutely not easier to read.

[@bigdbag]

I've realized over the years that team organization and larger organizational hierarchy is the best guide for how I approach construction of not only architecture but all the way down to coding patterns. How humans operate in an organization is a great guide to achieve goals like mitigating the rate of code rot and ease of replacing old code with new code.

[@CerikNguyen]

4:00 I had just cooked a really cool side project, figured all the tech stacks I want to use, super excited but a made the mistake to learn two new languages, 3 new concepts, all while learning how to exit nvim. It was not fun.

[@paulholsters7932]

I love writing code and creating a product. I don't care if it's bad or good. That are worries for later. I refactor as I go. But I guess it's different when you work in a team.

[@takeiteasyeh]

really summing it up from 2:00 to 4:15. every new project has to have something I havn't done before

[@joshmeyer8172]

7:40 "60% of the time it F's you every time" would make great merch

[@heap_or_stack]

This content changed my vision of programming for sure !

[@alfonzo6320]

17:25. this couldn't be further from the truth. Small function are the most reliable one since there is fewer possibilities for error. Once its written and tested, it should always do what it expected to do. Unless its a void function, then you don't event have to debug it. you simply check the return value is normal then you jump to the next statement. eg: you have a class that calculate hypotenuses, and has a triangle as ctor parameter. you could have a function that returns LengthA and another that returns LengthB. You might also wanna check if the triangle has a 90 degree angle before doing anything, thats another function right there. With that, your Calculate function does not care about how it gets the data, as long as the provided data is accurate. and it its not, congratulation, you figured out where the bug is, then you only have a 5-6 line function to debug instead of a big chunk. the calculate function would literally be 4 lines of code almost fully written in english.

[@user-hk3ej4hk7m]

I'd go with the physics professor take when explaining hot and cold and say "clean code is not clean, but the absence of shitty"

[@_skyyskater]

Need to add another comment. The solution to future-proofing your code isn't abstraction, it's literally the opposite, simplification. If you code is easy to read and understand, you can change it much more easily. If it's heavily abstracted as a means to avoid having to change it, you probably made bad assumptions and it will be harder to change--plus if those predictions never came to pass, which they usually don't, you're paying the cost of the penalty all the time no matter what. That's a bad insurance policy.

[@hosseines276]

25:56 "you don't want to end here" -- mean while building td in Vim XD

[@vladislavkaras491]

Thanks for all the commentaries!

[@gammalgris2497]

What is the best tool for a given problem Vs the tool people are most familiar with. Never thought about that before as the tools were often chosen (directly or as implication of an earlier decision) by someone that didn't have to work with them. Now I'm familiar with several tools and am wondering.

[@lorathas]

I agree with your friend. I've wasted too much of my professional career going through 20 something functions deep on code that should have been at most three levels of abstractions away. Way too many developers think about principles for the sake of principles, and don't think about things practically.