The harsh reality of good software

Recorded live on twitch, GET IN
/ theprimeagen
Become a backend engineer. Its my favorite site
boot.dev/?promo=PRIMEYT
This is also the best way to support me is to support yourself becoming a better backend engineer.
Reviewed video: • The Harsh Reality of G...
By: / @awesome-coding
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts

[@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.

[@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.

[@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.

[@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.

[@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.

[@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.

[@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.

[@truehighs7845]

Bit like the Police...

[@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.

[@zeuglcockatrice4633]

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

[@nuclearmedicineman6270]

You're like 99% there.

[@JorgetePanete]

is*

[@rocketpig1914]

It's a lie. Software isn't easy. Life isn't easy. But you can do them well.

[@AntonioDoesMetal]

The only time you're a "failure" is when you give up, everything else is just part of the process

[@eggsys7990]

"getting used to being a failure" Add: learn from it to overcome then you will found your self better software engineer @@SimonWoodburyForget

[@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.

[@michaelkolich1089]

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.

[@md2perpe]

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

[@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

[@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. 🤦‍♂️

[@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.

[@Tony-dp1rl]

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

[@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.

[@WhiteThunder121]

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

[@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.

[@macctosh]

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 🤔

[@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?

[@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.

[@Ultraporing]

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

[@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

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

[@alexanderkozhevnikov9087]

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.

[@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.

[@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.

[@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

[@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.

[@vladislavkaras491]

Thanks for all the commentaries!

[@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

[@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

[@chrisstadler7111]

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

[@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.

[@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'

[@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.

[@heap_or_stack]

This content changed my vision of programming for sure !

[@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 👏

[@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.

[@_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.

[@takeiteasyeh]

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

[@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

[@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.

[@lelilimon]

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

[@mroliveoil]

xD

[@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. - ???

[@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

[@terribletheo8401]

Congrats on 600 videos

[@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.

[@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.

[@tc2241]

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.

[@gyurkesm]

Please try to understand what he said! Readable code is desirable and you should try to write the best you can, but you should not use the phrase 'clean code' for that. Even if you don't mean it, people will think of Uncle Bob's clean code. Imo, even if somebody likes Uncle Bob's clean code style, it is not an universal 'you should write like this' clean code

[@alh-xj6gt]

It all depends. How much scaffolding the teem develops for their ease of use. For example something like hoogle (Hoogle is a Haskell API search engine, which allows you to search the Haskell libraries on Stackage by either function name, or by approximate type signature.) for other languages or specific to the project to help discover functions scattered through the project. When overall functions exceed some absurd numbers in a project some easy to use discovery needs to be made as grep or tagging just doesn't cut it after a subjective size. Or for example being stingy on abstraction and knowing when it happens can be very helpful and I'm an advocate to keep an eye out on premature abstraction as it is as hurtful as premature optimization, even worse as abstraction has no real measurement compared to optimization. But in prototyping when "time to prove of concept" is the only metric using some very lose and general approach outweighs the other concerns.

[@alexanderkozhevnikov9087]

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

[@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.

[@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.

[@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.

[@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.

[@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.

[@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

[@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.

[@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.

[@personalaccount1515]

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

[@undergroundo]

HOT TAKE: I rather create code that I feel proud about, enjoy every minute of programming, and MAKE LESS MONEY, than being more efficient but having no pride on my work and only find joy on my leisure time.

[@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.

[@ryanvarley2391]

I wonder what percentage of your videos you forgot to turn off alerts 😅 Loving the content though, it helps give me perspective on my skills and career!

[@jelanijackson3247]

Great POV on developer happiness/enjoyment

[@karljoyeux8845]

Excel roller coster blew my mind 🤯

[@carljacobs1287]

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!!

[@sucellos8621]

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

[@g.c955]

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

[@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.

[@kaerakh4267]

Being a good software developer is making something that meets requirements without being easily broken, that's hopefully not hard to service, which means that there is inherently room for improvement in the future, and that's ok. If you get hung up in the planning phase instead of the doing, you're likely doing something wrong. It's rare to make something perfectly the first time and on the VAST majority of projects it's fine for there to be touch ups after the fact. Business requirements also often radically change, so twisting you and your team into knots over something the business is likely to change their minds on isn't a good use of time and effort.

[@tabsc3489]

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

[@imerence6290]

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

[@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

[@nilfux]

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

[@Nightwulf1269]

Great video, thank you (and the guy you reacted to). I'm on the same page meanwhile. There are some basic rules like speaking names but other than that, many stuff is highly dependent on the purpose of the program you write, the language you write it in, your experience level and the one of your team mates and so on and so forth. Then, if it comes to performance or memory optimization, especially in embedded contexts or game code, calling 10 small functions instead of one bigger can impact on that. So for me, structuring the chunks of your program (packages, namespaces, whatever...depends on your language) as well as possible and do unit test the logic (!) of your code. No "100% coverage" stuff.

[@pmiddlet72]

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

[@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

[@Sina-xw4xp]

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!

[@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.

[@Dazza_Doo]

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

[@icusmilingAZ]

That curve works out better as a front end developer because once you start getting bored with a JS framework, it's time to start the next big thing! I've been doing websites for over 25 years, and I still always feel like a jr. because it's next to impossible to work with a single framework long enough to become a Sr., and if you do, you are 3-5 years behind what most companies are looking for...

[@sploders1019]

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

[@privacyvalued4134]

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.

[@Sancarn]

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

[@carlinhos10002]

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

[@jonmartintx1]

Gotta love the “Load Bearing Comments”

[@desmozGenes]

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

[@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.

[@mrmaniac9905]

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

[@alxk3995]

It's more or less the state of flow people can enter. The task needs to be interesting but not to hard or you get frustrated. Also not to easy or you get bored. Applies to almost any activity.

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

[@DarrenJohn10X]

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

[@lukei9772]

@Awesome MENTIONED LETS GOOOOOOOOO

[@neoncyber2001]

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.

[@user-qr4jf4tv2x]

"How do you laugh in bilions" - ThePrimeTime

[@ea_naseer]

write PHP

[@no-one_no1406]

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

[@gnagyusa]

I'm obsessed with code quality and performance. Sometimes I just think for a week or two about the right way to solve a problem before doing any coding. I can do this in my own projects, but you can't do it in a paid job, with deadlines, and bosses breathing down your neck. Also, companies tend to mandate the use of the worst programming languages and APIs So, sadly there's a *HUGE* difference in quality, performance and robustness between my own projects and the work I did as an employee. They are two completely different worlds.

[@hosseines276]

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

[@kylaxi]

25 years in coding and it work . Some things i build in the past ran with 4 code changes in 10 years. Old cobol and pl1 code worked and was good. Modern stuff gets changes all the time. People dont write code for the business anymore they are experimenting for their own skillset. Code quality does not matter because code only lives for 2 years max and the readability is not in de code logic but in the full chain of all the services involved imho