The harsh reality of good software 

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

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.

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

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.

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.

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

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.

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

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

what I understand from these kind of videos is that being a good software developer it's about getting used to being a failure, which is something I excel at

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.

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.

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

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

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

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

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.

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.

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.

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?

Completely disagree with his take one clean code. I’m not referring to Uncle Bob either. Clean, readable code is a thing and should be something that’s desirable. There are few instances imo where ugly illegible code is acceptable due to quirks and performance. Rarely are devs programming at such a level. Widely used libraries or not. Ugly code in most instances is lazy code.

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.)

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

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.

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

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

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

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

Thanks for all the commentaries!

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.

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.

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.

"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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

Congrats on 600 videos

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.

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

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.

This content changed my vision of programming for sure !

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

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.

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.

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.

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

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.

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.

The harsh reality of that rollercoaster enjoyment curve is actually extremely depressing

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.

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.

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 👏

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.)

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.

Nice video. What's this drawing tool you use? Is this some new version of Photoshop? :D I have no idea.

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

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.

My first boss (30 years ago), said that for ever 1000 lines of code there's a bug, and for every bug you fix you create another. 30 years later, I still agree!!

Your videos are therapy for me.

19:23 THIS! THIS! THIS! A million times. LET'S GO!

23:22 There is no man happier than Primeagen getting affirmation during a react video.

I write what I like to call "clean enough code". I keep my classes seperate, and generally try to write methods that do one conceptually generalized thing, and I try to keep the code organized enough that you can read the flow, but that's not always possible.

RE: The excel roller coaster, it should be noted that a lot of people don't have a choice but to stop there.

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.

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.

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.

Excel roller coster blew my mind 🤯

Great POV on developer happiness/enjoyment

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?

All problems can be solved by adding another layer of abstraction, except for having too many layers of abstraction.

"How do you laugh in bilions" - ThePrimeTime

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

This is a great example of the Dunning-Kruger Effect.

21:32 Nice Job Flick, you need a pay raise.

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.

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

The real coding wizards with 40+ years of experience have done the following.....looked at a breaking piece of code at 2am and asked "who the heck wrote this junk??" and then they saw their own name as the author at the top and remembered everything.

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.

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

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.

This “optimize code to read on stash” seems to be how the Linux Kernel developers operate. One reason Linus was against C++ was the fact that it comes with a lot of baggage and you need a lot of context to understand a little piece of code that usually isn’t there in the diff. It really makes you think about such trade offs.

Well structured, documented and properly tested code is pretty much possible and totally justifies the effort put into it, no for prototyping of course. Encapsulation is necessary for handling complex programs and teamwork. And yes refactoring is needed to adjust the code for further development. Clean code also exists! just because it's relative doesn't mean that it doesn't exist!

To add to the 'good enough' approach. That's fine for innovation, MVP for PoC, and for fairly low risk and reasonably low visibility processes that won't charlie foxtrot other things important to an org. But for everything else, a mantra I adopted long ago "You can do things right. Or you can do them again."

The best way to write software is to attempt to predict what a future feature request will be for any given unit in the software and then plan for that request to happen somewhere along down the road. You have to REALLY know your audience though or you'll just abstract everything and the result will be Java.

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).

words of comedicallyy-gold wisdom and equally wise responses to those harsh truths. thanks for sharing, signed a jr dev 1.5 year post grad

Thanks Prime, this was an awesome Awesome video reaction video.

@Awesome MENTIONED LETS GOOOOOOOOO

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.

Excel roller coaster? Wow! Now I want a c compiler in excel!

I try to only abstract things that are simple in principle and complicated in implementation, like TLS (just an example; I’m not doing my own crypto). TLS is exactly like a normal socket, but everything inside it is encrypted. Simple enough, but the process of encrypting the data traversing TLS is obscenely complicated, thus making it a perfect candidate for abstraction

we inherited a codebase, I'm trying to convince the project lead to not add optimizations without evidence of a performance issue. I say "we should make minimal necessary adjustments to ensure the delivery of the service given the tight deadline and avoid huge refactoring that could risk introducing unforeseen issue, which will add more workload." but it's hard when it's not your project....😅

I used to work with laser engravers. customers will get them working just enough to begin operations again. and i've seen millions of dollars wasted because they got the machine just barely running for the application rather than getting it fully maintained.