Unexpected Lessons I've Learned After 15 Years Of Coding

This is the closest you'll ever get to the "if I could go back what would I do different" video. I have some lessons in here I'm proud of

S/O Ph4se0n3 for the awesome edit 🙏

[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

[b_dawg_]

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

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

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

[jonbezeau]

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.

[dannyericson]

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!

[UzairSalim-dyuz]

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

[spageen]

The secret to coding well is to dye your hair

[crowlsyong]

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

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

[RiverReeves]

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.

[mrt_]

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.

[ThisIsNotAUsername-vo]

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.

[daveminion]

The only worker in the world today that truly deserves and NEEDSa union is -- sw devs, aka coders.

[lochieaxon]

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

[clarkflavor]

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

[MrSmith]

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

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

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