Unexpected Lessons I've Learned After 15 Years Of Coding

[@purplemongoose]

Strong "On the first day of your new job, squash every commit from the repo into a single commit with message "Legacy Code" and force-push to main" energy from Theo

[@schtormm]

LOL

[@lightning_11]

If that actually works, it's a solid way to teach your team to about the importance of protecting branches.

[@elmalleable]

FirstDay.activateLastDay(true)

[@prschorn]

​@@lightning_11 this. If as a newcomer you can push shit code to main, that's not your problem

[@lightning_11]

@@prschorn If you force push master and break the entire project in 5 minutes, consider your firing meeting as a recommendation to find a better team...

[@aritzolaba]

Starting aprox. at 4:50, your advice on how to get started with new (large) codebases, looking at the PRs rather than reading the code, is pure gold. Thanks a lot for this!

[@senaarth7868]

1. grow a mustache

[@marcelosyd]

Was going to say that. Get a mustache or won’t be a successful influencer 😂

[@elraito]

Gonestly he has that offender style with stashe

[@stackoverfloweth]

tough out there for women 💔

[@heuristix77]

@@elraito stache too thick, has surpassed offender and transcended to Tom Selleck-core

[@MichaelKire]

There's a difference between new dev to a new codebase and a senior dev to a new codebase. A senior might instantly know/see problem areas, where a green dev might see something but fail to see the bigger picture thus thinking its problematic when it isn't. That said, fast feedback is the key here. From other devs, from designers, from customers etc.

[@dennycrane2938]

I think the point being made was that, whether your a senior dev or a junior dev or a mid level dev, looking at the PRs instead of looking at the current state of the codebase is a much quicker route to understanding the current state of the codebase vs. being *aware* of the current state of the code base.

[@sealsharp]

The company i work at has nice collection of tools which were created to solve repeating tasks in a way that fits the requirement of the field. That is why we use some custom creations instead of basic open source solutions. I encourage new devs that join us to questions things to make sure they know that i will not be mad or see it as an insult because i want them to question it. a) sometimes it reveals an actual issue b) sometimes the answer is "oh yeah,i know it's not good, but we didn't get to fix/do it yet" and i had new colleagues to volunteer to dig into it. c) things that seem strange sometime are specific to our field so there often is a useful story to tell why things are what they are.

[@b_dawg_17]

“If you’re asking too many questions, it’s often because you were never taught how to find the answers.” I love this. Possibly my favorite quote of all the golden nuggets in this video.

[@UzairSalim-dy3uz]

there was so much to learn as a dev, I have been learning for almost two years every new technology but, finding your channel was one of the best things that happened to me, this way i can probably learn from much more experienced developer like you and have gotten so much value out of it . Thanks Theo for awesome work ..

[@dannyericson1]

I also read this article and really loved it! So much good stuff! Thank you Theo for all that you do for the developer community!

[@jonbezeau3124]

Deploy before commit is the webdev version "refactor hello world until it does what your app needs to"

[@MatiasKiviniemi]

First one is really something like "everyone in the team needs time and commitment to pick low hanging fruit". The way to do these little things is to immediatelly do it when you stumble upon it. Making a ticket just ends up in the "never important enough"-corner of the backlog. And the top reasons why people don't do it are a) They are under tight schedule deadlines and feel they can't spend half a day. Everyone needs to have "10% disposable schedule" most of the time. b) They don't feel they own the problem which is essentially a culture issue. Small issues need to matter to bosses and all devs need to be full citizens of the team.

[@RiverReeves23]

Thanks Theo, your vids really help to make the development community more healthy. I think devs are often abused in the corporate settings, like code monkeys and "mentored" by people who don't have people skills, so it helps to have this open conversation so eventually, we build healthy working environments for coders. I think likely, you've been in very healthy environments given you have worked for big companies that typically focus on work culture but having worked for smaller "big" companies myself, I've see some pretty toxic work cultures and that effects the development.

[@crowlsyong]

28:56 this feels so good to hear. I am often a bit shy to ask 'dumb questions'.

[@spageen]

The secret to coding well is to dye your hair

[@netgrok]

And having a magnificent moustache

[@jhenriquelc]

Don't forget the programming socks

[@MarcusHCrawford]

These guys are correct, the moustache and socks are also just as vital.

[@rjmunt]

Good advise on interviews. Assess your market value often.

[@MrSmith42]

I'm not even a programmer, but I found a lot of useful information in this video. Amazing article!

[@beowulf_of_wall_st]

Strong disagree on quality vs pace. The most galaxy brain insight you can have as an engineer is that the definition of code quality is"that which enables continuous and increasing velocity". if it's not making you faster in the long term that's not quality, it's complexity

[@m4rt_]

The answer is simple. Don't change anything. You are who you are because of all the mistakes you made in your past. If you prevented yourself from making those mistakes retroactively, you wouldn't have learned anything from them, and might make bigger mistakes in the future. Being told what mistakes to avoid, and learning why it should be avoided, is a big difference that can change a lot about how you avoid the mistakes.

[@thales-maciel]

you're effectively saying that "build more to make more mistakes" is better advice than your corny "don't change anything" advice. lol

[@clarkflavor]

I feel like I should listen to this on repeat for a while and really internalize these nuggets of developer wisdoms

[@pallenda]

Awesome video! I don't understand all the tech as I have only done some hobby python programming, but the wisdom in this video is very helpful.

[@ThisIsNotAUsername-v3o]

There's another piece of advice here. I'm guessing that the async recursion in Rust was tail call recursion, which doesn't generally cause a stack overflow. Normally, that's a good thing. Normally, a stack overflow is worse than any bug that might be caused otherwise. In a stack overflow scenario, that allocated heap would have likely been cleaned up, and the source of the bug would likely have been obvious. However, since the stack didn't overflow, the heap did, due to the web calls that the recursive call was making... Fixing a bug can reveal a bug that was "fixed", or whose behaviour was suppressed, by the first bug.

[@WilsontheWolf]

I want to chime in regarding debug stuff. Recently, I've got into modding of a game. I was kinda just hanging out in the modding community here and there, dabling a bit with stuff. However, I realized there was a bunch of issues that plagued a lot of people when messing around with stuff. The game itself had debuf tools, which were enabled with a super simple mod, but were not that useful outside more common situations. I took it upon myself to try just adding some additional functionality to the dev tools. I found just going, I want to be able to do X, and then digging through the codebase (which luckily for me is a proper code base and not so decompiled assembly) let me figure out how so much of the systems work and also build helpful tools. Its great to go through a codebase with the goal of getting x to work and understanding what is nessicary to get it to work and make a useful tool in the process. If this was an actual codebase I could write to, I would have made some changes to it in the process that would make some things easier, and further improve other peoples experience working on the codebase.

[@hazemkhaled9416]

I really hope I get someone like you as the one to ask I never had a more senior developer than me in any company ever Bad luck :(

[@jelliott3604]

I like asking "dumb" questions as, whilst a good number of people can may be able to give the(/a) correct answer a lot less know why it is the correct answer. You need to find someone who can give good answers to a chain of dumb questions - anyone can suggest how to do something, someone who knows "why" is much rarer - but they can give you the actual requirements

[@ShotgunAFlyboy]

I make a point to ask dumb questions and have normalized the practice on my team. Juniors occasionally thank me for it, and the questions it prompts them to ask are super helpful.

[@asdfractal8115]

I just joined a new team at work without an editorconfig, second PR was basically the whole repo amount of line change. Luckily it's a relatively new project in the company so wasn't too bad.

[@yugeyuge8008]

Great show Theo.

[@ironbutterfly3701]

Promise.all() is not making it running in parallel. Just the fact you called the functions without awaits in between. You can achieve the same by just calling functions that return promise and then call all the awaits later as needed.

[@carlosmspk]

What you said about calling first, awaiting later is definitely true, and it's the way I do it, but Promises.all() is definitely making it run in parallel (well, in that "parallel" way of single-thread javascript). Unless your point is that Promise.all doesn't have any magic behind it which causes them to run in parallel, it's just calling them in the standard way, in which case you're right, but I think that's what he meant

[@ironbutterfly3701]

​ @carlosmspk Yes, but some explanation: Problem Code: const a = await fetch(url1) const b = await fetch(url2) Solution 1: Using Promise.all const [a, b] = await Promise.all( fetch(url1), fetch(url2)) Solution 2: Doing in two steps: const aP = fetch(url1) const bP = fetch(url2) const a = await aP; const b = await bP; In practice I delay await until I need.

[@Huey-ec1]

@@ironbutterfly3701 Interesting, why delay await until you need?

[@ironbutterfly3701]

@@Huey-ec1 to avoid potentially blocking someone else.

[@Huey-ec1]

@@ironbutterfly3701 Thanks, that was a missing piece of understanding I've been wondering about for a while!

[@lochieaxon]

i wish younger me better understood the "you dont know your level" memo. only recently has this changed for me.

[@attilasedon9593]

Same I kind of felt that I was not on my actual level, but my boss said, do this, and learn that, and maybe, we may consider your promotion. Interviewed to somewhere else, and got a 30% more money and went from "medior" to senior position easily.

[@pp8884-ul1]

Thanks!

[@musicmikemn]

The example in the debugging a layer deeper point confused me. You have a user that logs out and gets redirected to the homepage. The homepage has a component that displays something about the current logged in user. Surely the intended behaviour is that logged in users can see their information but logged out users can't see theirs (or anyone elses...)? Swapping the redirect to happen first and then to remove the user state seems like a way of leaking information rather than fixing the issue? Also, the next example of looking up the commit history for bugs is made infinitely easier with proper observability with CI integration. It is magic when your monitoring tool can tell you which change introduced the bug.

[@millagoubenjamin]

If you have mechanism that, when not logged in, prevent the user to even mount components that should not be seen at all, (eg. Via redirection), it make sense that you use the same paradigm on logout and do not introduce extra checks that were not even needed in the beginning

[@LaserFur]

I find it is handy to have a file that enables or disables specific asserts all over the code base. This lets you turn on a assert for some event that normally you don't want to assert for. For example 16:29. you can add the null check and then add in an assert if it triggers. Then if some code always triggers it then global file can disable that assert.

[@InfiniteQuest86]

Yeah the one push back is spending an hour trying to solve something that can be done in a few minutes by asking about it. You can make the biggest leaps in understanding very quickly by banging your head against something. Whereas if they are like just run these two commands, then you still have no clue.

[@chameleonedm]

Now to inject a little bit of soft skills about *how* you correct major errors in a code base when you're new to a company Do NOT walk up to other devs and say "hey, this looks wrong". Go to the most experienced dev in the code base and ask "hey, why was this architected this way?" Sometimes there are very, very good reasons for best practices to be ignored. If the explanation you receive does not provide a good reason, go away and provide the solution before bemoaning about the error publicly. Architectural changes can be very political, and programmers can carry an ego, you want to get people on your side that have rapport with senior devs to back you up

[@Rope257]

1. Disagree. The code that doesn't change often most likely contains parts of the core domain of an application. Those are exactly the things you should be learning. Not in-depth, but in abstraction. 2. Agree. 3. Agree. 4. Agree. 5. Agree. 6. Agree. 7. Agree. 8. Disagree. If you're comfortable where you are there's no need to interview. If you're not, definitely interview. 9. Disagree. Some people are extremely good at programming, but not at the social aspect. Those people shouldn't be the face of a company. I would add a final one. 10. If you're answering a question and you don't know, simply say you don't know. You're not an imposter, you can't know everything and you're working in a team (most likely) exactly for that reason.

[@aaronbono4688]

Focusing on the poll request history doesn't help you understand the code better, it helps you understand the code you're most likely to have to work with better. If it hasn't shown up in the pull request history for a long time it's probably not very important at the moment but it is still part of the code you're just deprioritized spending any time on it.

[@aaronbono4688]

I have what I like to call the 15-minute rule where if you run into an issue you spent 15 minutes on it and if you're still stuck you have to ask for help. A lot of times 15 minutes is all you need to figure out how to fix it yourself but if it takes more than 15 minutes it's almost always faster to ask for help. This simple rule gives people a level of comfort that they're not unnecessarily pestering other members of the team.

[@MarkMark]

For most projects I have worked on over the past few years, I would 1. have our tests report code coverage %, AND 2. make it clear that it's totally ok to lower it (but the reviewer might ask why). As a result, folks like adding test coverage (and it grows - "you get what you measure"!), without the dysfunction that Theo described.

[@Huijiro-d5w]

It took me a while to find this video.

[@D_y_o_r]

Code coverage doesn't prove that tests test anything. Mutation testing of your tests helps you check and improve the quality of your tests.

[@dennycrane2938]

That's the rough part isn't it? Like you definitely want unit tests but you want unit tests that actually bring value and code coverage as a metric only tells you how many paths have a test that exercises it but it can't tell you if the test is worth a shit. I think this is why the community is starting to focus less on unit testing and more on behavioral testing from a consumer perspective. At least then your coverage, while still subjective, is more about the things you *should* test vs what you do test instead of the things that you *could* test vs what you do test.

[@ranjitbudhathoki8852]

We got Theo blaming others for clickbait before GTA 6. LFG🔥🔥🔥

[@ivanmaglica264]

7:20 I would not let a a freshly onboarded dev suggest what we need to change unless he/she is seasoned (10+ years) and has seen it before and has a solution that is battleground tested.

[@farhanghazali4406]

1. Learn to write proper unit test

[@muperdev]

Great Point

[@Eziekel666]

About the twitch case and the 100k line of covered codes. I hear often stories like this and I wonder if its not a communication skill issues, like the developers that see the problem give up too easily and don't phrase it well or communicate it well. Because I never had a CTO or even a PO not understanding thoses kinds of problems when exposed correctly, however I saw developers phrasing the thing poorly like "I have a fix that is going to drop our coverage below 80%, its useless code anyway" which is not going to have a approval without good explainations and then the dev don't bother and is like "its stupid they don't get it its fine i just do what im asked" instantly When there is a point like this 95% of devs are able to see the problem so just making a poll or a message in slack that get upvoted by everyone is enough.

[@sharjello]

I can relate to this Me after 15 years: "I finally have the feeling that I'm a decent programmer."

[@husseinyoussef6998]

Very beneficial content 🫡

[@ShotgunAFlyboy]

Lines of code is a bad coverage metric. Branches (which basically means decisions/logic) is the coverage metric that catches the most bugs.

[@jordanmancini]

There are no dumb questions except the ones not asked. It should be encouraged for new devs to ask questions because not everyone is gonna know everything about the codebase or have the same strengths in technical background.

[@soumalya]

10:21 I'm in the 2nd company and its am headache.. Life is so much easier on the other side.. To all who are on the 1st type of company move fast and fail fast because you can

[@kshitijk14]

honestly learned a shit loads of things

[@tobiasjennerjahn8659]

41:24 Shit, this one hit hard for me. I'm guilty of doing this (or rather not doing this), as well has having worked on projects where that didn't count as acceptable feedback.

[@DrNefariousX]

Why couldn't you have shipped zero known bugs to production instead? The premise that it's an advantage to ship bugs, is the creation of technical debt. And the fact that someone reported it, is great, but how many users were impacted by that bug and didn't report it. At that point, fixing bugs that have gone to production, are always more costly to fix than if they had just been fixed while in DEV, which also includes the time the customer spent fighting your bug, reporting the bug, having the user potentially re-explain the bug to you for clarity, logging the bug at some point (instead of just fixing it), and then taking that tracked bug and reporting that you've fixed it and potentially communicating it to your Project Manager, having meetings about prioritizing which bugs to fix, etc. There's also the peace of mind that comes with you having released code without a production incident. If the bugs are found afterward, that's fine. You didn't catch them. And this isn't me saying release perfect code. I'm saying, release code that doesn't impact your customers or their view of your software product. By fixing the bugs you know about. If you don't have to retain any mental baggage to remember to fix bugs, that's awesome! Also, if you're letting bugs go to PROD, you're missing the opportunity that lets you find a second bug that was being masked by the first bug, which is a thing.

[@ProjSHiNKiROU]

Someone has to rewrite/reconfigure the code coverage formula for the situations where high-coverage code being deleted reduces total coverage. Some coverage checkers have different thresholds for new lines vs. the entire codebase

[@Divyv520]

Hey Theo , really nice video ! I was wondering if I could help you with more Quality Editing in your videos and also make a highly engaging Thumbnail and also help you with the overall youtube strategy and growth ! Pls let me know what do you think ?

[@0xBerto]

3:41 😂 I can’t fuckn help it. Autism kicks in and open my mouth hahahah

[@theonecrufix]

30:48 I spent 3 hours one day trying to get my k8s dev environment running only to later ask our lead dev what might be happening. He was working on a bug fix and added 2 environment variables to his config maps that I was missing. I updated my config maps then applied the changes and it began working immediately.

[@michaelschmid2311]

3:11 i once did this,implemented await promise.all thinking these devs are stupid only to realize the sap api for that endpoint cant handle 2 Transactions at the same time. For this endpoint SAP locked their Database Table (not just that single item) during updating of said items... Its the easiest fix to prevent incorrect data. But could be solves better in many way. If i had a penny for every time i was held back by shitty apis, i couldve probably retired by now.

[@ThisIsNotAUsername-v3o]

Premature feature development should be thrown in a more dangerous containment bin than premature optimization. At least if you find yourself bored on a Friday night and decide to try to speed up this one function, you probably won't mess up your entire project development. Premature optimization can be wasteful and pointless, but it's your Friday night. Premature feature development can alter API. Also, by the time you actually get there, someone might have a better solution. ...I may end up ripping some code out of a personal project, later... .> x.x

[@aiamfree]

watching this after upload thing crash is what's the word...

[@pierrotlasticot5848]

prettier's print width mandatory rule is a dealbreaker to me

[@MarkMark]

A fun story: a teammate was working on a large-ish (a few days worth of work) piece of functionality, which, at the end of the day, would produce data, serialized into a json string. Our manager: "why is this such a big project, does this not just generate a string?" Me: "🤦Yes, it does! Kind of like ChatGPT!"

[@devmamba2492]

funny how dumb your story is

[@NickTheCodeMechanic]

I'd just return an empty User object defined in JS (or, God forbid, Typescript). That way the next guy can reason about validating and properly initializing what you left him: a null object. This of course assumes you have some sort of .validate() function that takes a User and throws on nulls, empties or invalid fields. Extra work? Not really. The more fields you have in User, the more accurate and guess-free your validation AND null-checking will have to be, because you're likely to render that User and with more fields, it will be quicker for you and your team to fill out that null object User. Bugs are good. Use them on purpose to prevent and uncover logic bugs.

[@mohamedyamani8502]

could you share the tweet's link? The one of Huijiro?

[@MarcusHCrawford]

“How I would learn to code if I didn’t quit learning to code in order to make videos about learning to code.” So many of those “learn to code” scam videos are done by channels with all the experience of a junior in college-not even the level of a junior programmer. Not everyone can be as cool as the mustache boys-Theo and Primeagen. These boys eat, sleep, and poop code.

[@kr4156]

where the hell are yall finding these articles.. I wanted to read em but didn't find shi

[@roebucksruin]

Haha. "Dumb questions rule." I ask maybe too many dumb questions, but I'd rather give someone smarter than me the opportunity to agree or correct me. Letting dumb ideas fester doesn't help anyone.

[@gantushigsaruul2489]

Arc eats so much ram... even more than chrome

[@TylerJusCodes]

So how do you learn about a codebase from the commits if it has 10,000 commits 😒

[@louisv9447]

That haircut needs to comeback 😂😂

[@swodaw1247]

Bro just looks like nick white 💀

[@pencilcheck]

I would tell myself that I should learn react and JavaScript and join the winner companies then I will be insanely rich

[@steve-adams]

The whole "make it easy to get into different app states" thing is invaluable. I didn't realize until embarrassingly recently. I started using state machines more and discovered I could essentially rehydrate them into various valid states whenever I pleased, so started using that strategy for testing in order to test specific things within tests without needing to traverse several states to get to the one I wanted to test. Long story short: I realized I could do this while debugging as well. I created a little command panel to reveal in the top right of my page which lists all machines in the system and each has a dropdown of states I can put them into. It's so fast and easy to get where I need to be, know it's a valid state, know it's exactly what my user will see, and know that what's going wrong or the behaviour I want to observe will reliably occur. This combines with snapshot diffs on the state machines is like... I don't know, my work is practically done for me now. State machines don't belong everywhere, but the same principles are valid and at least partially possible to implement anywhere. I wish I started doing this 15 years ago.

[@moshiez]

Can you elaborate on why you think otel is a shit standard?

[@vinialves12362]

what's slow shipping?

[@johngagon]

Incidental complexity? : FP's monadic bifunctors yadda yadda.

[@granatun]

Damn, you still clickbaited. Edit: the advice is crazy good.

[@helloworldcsofficial]

Nice. More of these vids! Good to learn from the more experienced devs.

[@PatrickMetzdorf]

So this is lessons the other guy learned, which is useful, sure. But what about your own list?

[@xingzhexin8843]

Just a reminder that the mic volume is capping in this video, might wanna turn it down a notch.

[@ikirachen]

JIRA as a religion :)

[@AloisMahdal]

Intentionally allowing bugs so that you can "make impression" on your customer is ethically questionable at best. It's also foolish: having a customer happy and loyal because you fixed their pain point can stroke ego but how many customers will just leave because the smell of jank all over your product?

[@dennycrane2938]

You may have missed the message there. Saying "err to bad code" is ver much not the same thing as saying to deliberately place bad code in production. There is no ethical dilemma. The statement is favoring functioning code over "complete" code. As crass as it comes off, this is the source code equivalent of "fail fast and iterate" but with the added benefit of "don't spend too much time trying to solve problems you don't even have yet" built into it.

[@rjmunt]

First pull request at a company is a 100000 line PR? If that wasnt a pure formatting PR ... GTFO don't let the door hit you on your way out.

[@NickTheCodeMechanic]

if(!user) return null; has me triggered....

[@deadviny]

What's with these comments? Some *weird* corner of the internet found him? Edit: oh, he keeps pooping on ladybird

[@QuentinDurot]

37:13 Truth

[@scrapycholo2659]

Keep complaining on Twitter😂❤

[@Guergeiro]

Uhhhh, promise.all and parallelism... Concurrency != Parallelism

[@Qrzychu92]

the diferrence is "start 1, await 1, start 2, await 2, start 3, await 3" and "start 1, start 2, start 3, await 1, await 2, await 3" - the latter is faster if any IO is involved

[@Guergeiro]

@@Qrzychu92 I'm not saying it's not faster, just saying it's not parallel.

[@Qrzychu92]

@@Guergeiro the IO certainly is :) that's why it's faster. If it wasn't parallel, then it would not be faster

[@SeanJMay]

If they are DB connections, file downloads, network calls, GPU command sequences, WebWorker or ServiceWorker dispatches, cross- messages, IndexedDB transactions, et cetera, they are very much parallel, and they are concurrently brought back into the main thread, inside of microtasks, at the end of a callstack, when the response is received. Thus, if you are blocking on the first one, before submitting the second or the third, it's very much going to change the resulting time, because they are very much capable of being processed in the background (eg: browsers will typically allow 6 assets to be simultaneously downloaded from a single domain ... or allow 6 connections to that domain to be open, simultaneously).

[@aditya.khapre]

If you just want to read a blog, why are you making a video?

[@orionh5535]

Don't learn javascript

[@gamechannel1271]

Javascript is fine, if you can't handle it that's a serious skill issue.

[@TomNook.]

Young Theo looks so mid

[@gustavbw]

10:30 - Quick note: Yes, you can be overly cautious, but do not confuse stuff like proper logging and error handling, with testing. No amount of tests will help you fix a bug, if you never set up logging, nor will no amount of logging prevent a bug - it will however make it significantly easier to squash it later. Sure, break some stuff, ship a bug or two, but don't wait for the bugs before you do your error handling. (as Theo mentions; "if we fixed it FAST enough, the customer would be more loyal..:" also I've been but a junior dev for a year now, so idk y I feel like I got something to add here)

[@skylerdjy]

We have an entire component library at work in storybook and i swear i only use it for the icons i need

[@maddada]

الله يجزيك عنا خير جزاء

[@zilahi8]

theo, you did not code for 15 years. cmon dont lie, theres literally no reason for that

[@cocoscacao6102]

Simple really. Learn how to make something more advanced than a hello world (make sure it's in JS), put a stupid haircut, read other people's articles, and make sure you deliver what the lowest common denominator wants to hear... You now have a successful YT career... Welcome to the club, JS influencer...

[@rasi_rawss]

early

[@snipernosnipey8162]

You would stop being so cringe

[@rasibn]

Why hating lil bro? Nothing better to do in life?

[@viratzz]

first viewer lesgo