The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024

[@ruixue6955]

2:41 get Job done 3:10 resist procrastinating 4:12 know you dont know 4:46 iterate wildly 6:24 build a product 7:36 no emotional investment in my code 9:13 study the domain 10:22 watch your users 13:04 solve for now 14:58 learn to see what is really there 17:43 solve the real problem 20:04 choose the right tool 21:15 data outlives code and the organizations 24:46 do the simplest thing, not the easiest 26:44 make the change easy 27:14 27:30 replacable component architecture 28:00 spike and stabilise 28:56 reduce, reuse, recycle 29:53 31:02 be a polyglot 31:09 explore languages, tools, paradigms 33:29 be full-stack 34:10 be really full-stack

[@964tractorboy]

I wish more people could have seen this talk in past years and decades. It really hit-home for me. Excellent. Thanks.

[@refreshcrazyname]

The maintainability of the code is an important part of "the product". Far to many systems are build solely focusing on the "Product" as seen from the users perspective only, which always end up in systems being hard and expensive to maintain, expand and improve. Caring about the code and the product are not each others opposites, you can't do one without the other.

[@weekendresearcher]

“He slept beneath the moon, he basked beneath the sun; he lived a life of going to do and died with nothing done.” - James Albery

[@andy12829]

@@weekendresearcher Actually that's how life should be , natural. The hustlers will bask under moon 🌝 and make everybody's life hell 🌚

[@mitaasy]

“Who is gonna remember you working late to office?” - for sure kids gonna remember that Wonderful wonderful talk, wish we have more speakers and leaders like him in the industry

[@refreshcrazyname]

100% agree with the people skills and safe environment of the team. This is how you allow people to grow.

[@ximono]

Brilliant (and provocative) talk! TL;DW: Adopt a Unix hacker mentality (but not the stereotypical asocial behaviour and working late hours). Be kind (to yourself and others). I really liked Part 3: Caring about the team. Very very important.

[@marcusolk9652]

In these dull and desperate times bright minds are so important. Dan, you made my day. Once more. Thanks and please: never stop doing what you do, mate. Cheers

[@fabrizioalonzi4122]

The first point is fundamental. Perfection is the enemy of success. Procrastinate because you have to learn the cool language of the moment, the new released framework, etc. Then Pieter Levels comes along with PHP, JQuery and working on a PC/microwave oven, puts the same project online in a week. We have arrived in an era where there are too many developers and too little stuff actually developed.

[@jjmalm]

I think one thing to add at the end, recognise when the team doesn't care about you and have a strategy to get out. The part about staying connected in different things and having a good network will save you: leveraging your community so if you do need to leave a bad situation it won't be reactionary and under pressure. Having exit plan means your working life will unfold much more on your own terms and this destresses the mind significantly.

[@fyodorx5428]

The point about dependencies is spot on: you add a small library and now suddenly your app depends on entire Github. One of those things has a vulnerability and you have a headache upgrading everything.

[@Syntax753]

Kudos for mentioning Advent of Code! I have made almost identical talks to this one with fellow colleagues for nearly 30 years, so it's good to know I am not the only one who has these views :)

[@drys262]

Nice talk Dan! This is really insightful. Thanks

[@Jebusankel]

I'm glad Dan survived the fire to give this talk

[@Thorax232]

couldn't disagree more with the idea of writing bad code and not worrying about maintaining it. My entire career has been cleaning up after full time developers who don't know how to code. They're too used to someone wiping their ass for them. In many situations it's impossible to keep up with the amount of bugs these people produce. They don't deserve their jobs.

[@JeffryGonzalezHt]

Fantastic. So many gems - the Eric Meijer thing - the difference between application development and library/framework/language development is huge.

[@cmdr_thrudd]

Great talk and nice to have some external validation on things I've said to my own teams over the years 😊

[@antonpetrovmain]

Lovely talk, thank you so much for the insights and the motivation!

[@user-my6yf1st8z]

cleared my head, thanks. great talk🙌

[@daniel.marbach]

Thank you for this wonderful talk Dan!

[@trudyandgeorge]

Fantastic talk. It hit hard for me.

[@coolsebz]

Dan's one of the best, hats off!

[@MattGodbolt]

Really great talk! Thanks Dan!

[@StevenvanderMerweProfile]

Great talk, thank you

[@ximono]

19:55 Question to the speaker: You skipped over "Write the README, then reduce the embarrassment!", probably due to time. Could you elaborate on that in a comment?

[@kahnfatman]

Have you ever criticize a child before their parents? What is the parents' reaction? Who is more defensive? Who gets the blame? Is there a difference between the two parents? Is there a difference in the reactions if the child is a boy or a girl? Code is an actual brainchild of us engineers/developers. Our personality will kick differently when our code is criticized. Handle criticism well for well intended purposes without putting "the self of yours" in there and you will become great.

[@databasemadness]

Brilliant talk!

[@19Adler91]

Great talk. Unfortunately, small percentage of IT industry know these principles.

[@watherby29]

I am researching here

[@alvaromoe]

I didn't know Michael Keaton was such a good programmer!

[@aw2269]

The Best Programmer - the one that do not have to deal with Po, Scrum Master, Train, ART etc.

[@stzi7691]

This talk is only partly good. Because it does not reflect practice in alot of SWE jobs nowadays. Especially the card with writing bad code: "You will rewrite it." . This never gonna happen. You product manager thinks this crap is very much good enough, because YOUR very costly working hours need to be reduced. Stuff goes to production and to the customer and fails. And then you are guilty. You are always guilty. THAT is corporate software engineering in a nutshell. Just starting without having a plan is dumb. Planning too much without starting is even more dumb. You have to find the sweet spot.

[@gonzalomunoz2767]

I don't think he meant shipping crappy code to prod, it's about starting at whatever level of competency your first line is, and then the moment you found a better way, just change what you wrote 10 mins ago. Then, when everything is good and ready, ship a good solution at which you arrived incrementally, instead of spending the whole day daydreaming about the moment you come up with the perfectly architected implementation, which will never actually happen

[@fdevl]

@@gonzalomunoz2767 If you are not a very fast coder there is a limit of how many iterations you can have before the company next goal. In very enterprise businesses where product features reign, this can be very unrealistic. Besides, understanding a better way in many cases require research which increases the lead time for your code delivery, unless you can iterate on your own work seamlessly which from personal experience applies to smaller rather than larger portion of developers. A bit of research before jumping into code can go a long way.

[@RockTo11]

This sounds like Compression Programming.

[@geoblk3000]

He minimized the time to get into the flow state

[@stzi7691]

Building a product with no code? This is an ideal that is described but not achievable (like dancing on a cloud just by feet). Fact is your code .... is also a product. Yes, it has a purpose to provide a function and a wizard that the customer wants. But it is a crucial part of the product. And if you write crappy code, you basically write a crappy product, right? The ony thing Daniel Terhorts-North gets very right is: "Have no emotional attachment to your code.". I would even say kill your darlings regularly. But in order to do that changes easily your first code should not be absolute dogwater, ok?

[@cmdr_thrudd]

I think the point he was making about making a product without code was by leveraging existing products to cobble together a business solution. I've done it a few times for startups. I see my job as a developer is to solve a business problem not to write code, just it usualy requires code 😂

[@gonzalomunoz2767]

@@cmdr_thrudd Yeah you can spend the next semester implementing a bespoke CMS having exactly anything and everything your sales team wants, or just make them use Excel so they can actually sell stuff. "No code" as a term is older than the current popular meaning. In this case, it can mean "someone else's code", or even eliminating a problem instead of fixing it

[@WilliamCulver]

Brilliant talk but speaker should probably try to quit smoking, its clearly not working out too well :)

[@stzi7691]

Ok, It is the start of the talk that is crap. The rest is very much ok.

[@2pythonblog]

I am gonna pause this watching at 6:09, go back to my WIP side project, gonna push it a bit to MVP, and then go back watching this. Please wait for me 😢

[@Tothefutureand]

22:40

[@extravaganza69]

@24:20 and they leave the project in blossoms jumping to something else while you join this project and need to maintain and develop thia utter piece of sh...