25 Lessons from 25 Years 🔗 **Source:** [25 Lessons from 25 Years](https://www.youtube.com/watch?v=cyxQ82L298Y) > [!note]+ Document Notes > tags: [software-development, career-advice, team-collaboration] > author: Ross Wintle > source: LoopConf > reference: https://www.youtube.com/watch?v=cyxQ82L298Y > date created: 2024-12-19 14:30 > > # 🏷️ Title: 25 Lessons from 25 Years > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Create personal README/user guide — understand working styles #teamwork - [H2] Set up text expansion and clipboard history tools — reduce typing friction #productivity - [H3] Start keeping an awesome log and achievement journal — track accomplishments #self-care ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [BaseCode Field Guide to Writing Good Code](https://basecodefieldguide.com) - [Manual of Me](https://manualof.me) ## 📝 Summary - Ross Wintle shares 25 career lessons in three acts: working with people, coding challenges, and self-care - Emphasizes open-mindedness as the overarching theme connecting all lessons - Key areas include team collaboration, code quality, personal well-being, and professional development - Practical advice ranges from technical skills to mental health and career growth - Bottom line: Be open-minded about people, technology, and taking care of yourself ## 📖 Main Content Ross Wintle presents lessons learned from 25+ years in software development, structured as three acts. Act One ("People are Hard") covers teamwork challenges including opinion management, team dynamics, diversity benefits, and communication skills. Act Two ("Coding is Hard") addresses technical practices like writing readable code, avoiding bugs, learning operators deeply, and maintaining standards. Act Three ("You are Squishy") focuses on self-care including writing things down, finding mentors, physical movement, investing in good equipment, and maintaining confidence through achievement tracking. The presentation emphasizes that open-mindedness underlies all effective development practices. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=cyxQ82L298Y&t=0) — [H1] Introduction and Format - Key idea: Presenting 25 lessons as mini-conference with interactive resource - Evidence: "Each of my topics could be a lightning talk or a full conference talk of its own" #### ⏱️ [03:45](https://www.youtube.com/watch?v=cyxQ82L298Y&t=225) — [H2] Opinions vs Facts - Key idea: Distinguish between opinions and facts, remain open to changing views - Evidence: "Sometimes we hold opinions too hard, and we need to think about letting them go" #### ⏱️ [05:30](https://www.youtube.com/watch?v=cyxQ82L298Y&t=330) — [H2] High Standards, Low Expectations - Key idea: Expect a lot of yourself and little of the world - Evidence: "Life is easier when you expect a lot of yourself and little of the world" #### ⏱️ [07:15](https://www.youtube.com/watch?v=cyxQ82L298Y&t=435) — [H2] Engineering as Team Sport - Key idea: Software development requires collaboration with different roles and strengths - Evidence: "People have different strengths and weaknesses and they train specifically for their roles" #### ⏱️ [08:45](https://www.youtube.com/watch?v=cyxQ82L298Y&t=525) — [H2] Understanding Different Brain Types - Key idea: Everyone's brain works differently, use personality tests and user guides - Evidence: "Being a relator is quite unusual on a team of software developers" #### ⏱️ [11:30](https://www.youtube.com/watch?v=cyxQ82L298Y&t=690) — [H1] Diversity Benefits - Key idea: Diverse teams perform significantly better across multiple metrics - Evidence: "2.5 times higher cash flow per employee, 35% more productive, better decisions 87% of the time" #### ⏱️ [13:15](https://www.youtube.com/watch?v=cyxQ82L298Y&t=795) — [H2] You Don't Know What's Going On With People - Key idea: Be kind and give grace because you don't know others' circumstances - Evidence: "Sometimes I arrive at my desk and need to sit down for 10 minutes with a cup of tea" #### ⏱️ [15:00](https://www.youtube.com/watch?v=cyxQ82L298Y&t=900) — [H2] Say Nice Things and Give Feedback - Key idea: Praise good work specifically and learn to give/receive feedback well - Evidence: "Be specific because saying great job on its own isn't actually very much" #### ⏱️ [17:30](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1050) — [H1] Write Simple, Readable Code - Key idea: Code is for humans, not just computers - Evidence: "Code is for other humans. That might be you at a later point in time" #### ⏱️ [19:00](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1140) — [H2] Read Your Own Code - Key idea: Review your own code before submitting to find bugs and improve clarity - Evidence: "You will find bugs, you will find badly named variables" #### ⏱️ [20:15](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1215) — [H2] Don't Be Too Clever - Key idea: Avoid writing overly complex code that others can't understand - Evidence: Shows examples of unnecessarily clever code that's hard to maintain #### ⏱️ [21:45](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1305) — [H2] Don't Fix Bugs, Avoid Them - Key idea: Invest time upfront in requirements, testing, and analysis to prevent bugs - Evidence: Contrasts SpaceX iterative approach with space shuttle's engineered reliability #### ⏱️ [23:30](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1410) — [H2] Learn Operators Deeply - Key idea: Don't assume you understand basic operators like +, -, = - Evidence: JavaScript example showing "I am 25 years old" becomes "NaN years old" #### ⏱️ [25:00](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1500) — [H2] Old Things Can Be Good - Key idea: Don't dismiss old software/plugins, they often contain valuable knowledge - Evidence: "WP Migrate product... incredible how much historical knowledge is built into this plugin" #### ⏱️ [26:45](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1605) — [H2] Look Outside Your Bubble - Key idea: Learn from other ecosystems and bring good practices back to WordPress - Evidence: "I've benefited so much by looking at the Laravel ecosystem" #### ⏱️ [28:00](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1680) — [H2] Standards Are Good - Key idea: Pick coding standards and automate them rather than debating preferences - Evidence: Mentions Juliet's work on PHP CodeSniffer and WordPress coding standards #### ⏱️ [29:30](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1770) — [H3] What If Software Could Be Finished - Key idea: Consider what it would take to write truly finished software - Evidence: Game Boy with 35-year-old software that "has never been updated and is completely free of bugs" #### ⏱️ [31:15](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1875) — [H2] Write Things Down to Forget Them - Key idea: Writing helps clear your mind and preserve knowledge - Evidence: "Writing things down isn't just for remembering things, it's for forgetting them" #### ⏱️ [32:30](https://www.youtube.com/watch?v=cyxQ82L298Y&t=1950) — [H2] Ask People to Mentor You - Key idea: Directly ask respected people to mentor you - Evidence: "The worst thing that can happen... is that they say no and they're incredibly flattered" #### ⏱️ [33:45](https://www.youtube.com/watch?v=cyxQ82L298Y&t=2025) — [H2] Move Around Frequently - Key idea: Take breaks at least once an hour and use sit-stand desk - Evidence: "RSI... the only thing that helped... is taking really frequent breaks" #### ⏱️ [35:00](https://www.youtube.com/watch?v=cyxQ82L298Y&t=2100) — [H2] Buy Good Equipment - Key idea: Invest in quality tools like mice, keyboards, chairs, monitors - Evidence: "I bought like a 60 pound mouse... this thing's flipping amazing" #### ⏱️ [36:15](https://www.youtube.com/watch?v=cyxQ82L298Y&t=2175) — [H2] Type Less, Smile More - Key idea: Use tools like text expansion and clipboard history to reduce friction - Evidence: Shows difficulty typing "function" and "$this" accurately #### ⏱️ [37:30](https://www.youtube.com/watch?v=cyxQ82L298Y&t=2250) — [H1] Remember You Are Awesome - Key idea: Keep an awesome log and achievement journal for confidence and career growth - Evidence: "Record nice things that people say about you... with metrics and statistics" #### ⏱️ [39:00](https://www.youtube.com/watch?v=cyxQ82L298Y&t=2340) — [H1] Be Open-Minded - Key idea: Open-mindedness underlies all other lessons about people, technology, and self-care - Evidence: "Open-minded developers are more productive, they're happier, and they're more valuable" ## 📚 References - [BaseCode Field Guide to Writing Good Code](https://basecodefieldguide.com) - [Manual of Me](https://manualof.me) - [16 Personalities](https://www.16personalities.com) - [Clifton Strengths](https://www.gallup.com/cliftonstrengths/) ## 🗣️ Paraphrase - Distinguish between opinions and facts, remain open to changing your views through understanding others' perspectives - Focus on high personal standards while having realistic expectations of others and systems around you - Embrace diversity in teams as it demonstrably improves performance, productivity, and decision-making quality - Write code primarily for human readers, not computers, emphasizing simplicity and readability over cleverness - Prioritize preventing bugs through upfront planning rather than fixing them after they occur - Take care of your physical and mental health through regular movement, good equipment, and tracking achievements ## 📰 Newsletter **25 Career Lessons Every WordPress Developer Should Know** Ross Wintle's presentation at LoopConf offers practical wisdom from 25+ years in software development, with valuable insights for WordPress professionals at any career stage. **Key Takeaways:** - **Team Collaboration**: Understanding different personality types and working styles improves team performance. Consider creating a personal README to help colleagues understand how you work best. - **Code Quality**: Write simple, readable code for humans first. The BaseCode Field Guide to Writing Good Code is recommended reading for improving your coding practices. - **Self-Care**: Regular movement, quality equipment, and maintaining an "awesome log" of achievements support long-term career success. The overarching message? Be open-minded about people, technology, and taking care of yourself. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create content around "25 lessons" format for community engagement - Education: Develop workshop content on soft skills for developers - Developer experience: Improve onboarding with personality assessment integration - Developer marketing: Highlight diversity benefits in recruitment campaigns - Community management: Implement mentorship matching programs #### WordPress - Core: Promote coding standards adoption through better tooling integration - Community: Create mentorship programs connecting experienced and new contributors - Training: Develop lesson plans around teamwork and collaboration skills - Documentation: Add guidance on writing readable, maintainable code - Accessibility: Ensure mentorship programs are accessible to diverse participants ## 🧪 Hypotheses - Teams using personality assessments and personal READMEs will have better collaboration outcomes - Developers who maintain achievement logs will have more successful career transitions - Organizations implementing frequent break reminders will see reduced RSI incidents - Code review processes that include praise alongside criticism will improve team morale ### 📊 Methodology - Survey teams before/after implementing personal README practices - Track career progression metrics for developers using achievement logs - Monitor health outcomes in organizations with movement-focused policies - Measure code review satisfaction and team retention rates ### ❓ Questions - How can organizations systematically implement diversity practices beyond hiring? - What specific metrics best demonstrate the ROI of investing in developer equipment? - How do different personality types respond to various feedback delivery methods? ### 🔮 Future Research - Longitudinal study on career outcomes for developers using systematic self-documentation - Analysis of bug prevention techniques across different development methodologies - Investigation of physical health interventions in remote development teams ### 💡 Implications - Practice: Regular self-reflection and documentation improves career trajectory - Policy: Organizations need structured approaches to supporting developer well-being - Security: Code review practices should balance technical and human factors - Education: Soft skills training is as important as technical skill development - Funding: Investment in developer experience and equipment pays long-term dividends ### 🧠 Learning Styles Assessment Reading level estimate: 8th grade (accessible to broad audience) #### 👀 Visual learners - Present: Slides with clear structure, code examples, visual metaphors - Improve: Add flowcharts showing career progression, team dynamics diagrams #### 🔊 Aural learners - Present: Full video presentation with clear narration - Improve: Companion podcast discussing lessons in depth #### 🗣️ Verbal learners - Present: Clear explanations, analogies (dishwasher loading, Game Boy example) - Improve: Discussion prompts for each lesson, storytelling elements #### 🧩 Kinesthetic learners - Present: Interactive resource website, practical action items - Improve: Hands-on workshops, role-playing exercises for difficult conversations #### 🧠 Logical learners - Present: Numbered lessons, clear structure, data on diversity benefits - Improve: Decision trees for applying lessons, measurable outcomes #### 🧑‍🤝‍🧑 Social learners - Present: Conference setting, team-focused content, mentorship emphasis - Improve: Study group guides, peer accountability systems #### 🧘‍♀️ Solitary learners - Present: Personal reflection prompts, individual achievement tracking - Improve: Self-assessment tools, private journaling exercises #### 🌿 Naturalistic learners - Present: Organic career growth concepts, ecosystem thinking - Improve: Natural metaphors for team dynamics, growth cycles ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Well-structured headings in slides, clear navigation <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=cyxQ82L298Y)* **[00:00]** Hi, Loopcom. Uh, welcome to London if you have come from afar. Um, I am here to present you 25 lessons from my 25 plus. There's a couple more uh years in software development. And if you take out the outro and the intro and the outro, I'm going to try and do it in about 25 minutes. I will not actually do it in 25 minutes, but I'm the 25's all kind of lined up and it seemed like a good idea. But when I look at this, I think, "Oh my goodness, what on earth **[00:31]** have I done?" And I presented two talks uh to Brian as options and he chose this one and so now I have to deliver it. My clock is ticking here. Um there's a lot to get through quite clearly. Um, so let's crack straight on with lesson one, which is don't submit fun talk ideas to conferences because someone like Brian is going to pick them out and make you deliver them. Thank you, sir. [laughter] The way this is going to work, this is **[01:01]** like a mini conference within a conference. Each of my topics could be a lightning talk or a full conference talk of its own. And I'm banking on the fact that you're all smart people. So, put your hand up if you are sat next to someone that you think is smart. That's everybody, Gary. You're all at loop comp, so you're all by default smart people. You've all got your devices. Uh, you've all got the ability to use the internet and learn **[01:33]** new things. So, I have made a little resource. Get your cameras out, scan this, or type it into your phones, and there will be a little web page with 25 numbers on it. And you can tap the numbers for the lessons that you're interested in. And if my timestamps are right, if I am actually a good developer, at the end of the talk or towards the end of the talk, all the talk titles will unlock and you'll be able to tap a little button to get your own personalized show notes. Hopefully that will all work. And if it doesn't, come to me afterwards and tell **[02:05]** me that it doesn't work. Um, and the idea is that because I can't go into any one topic in depth, um, the idea is that hopefully I'll be able to inspire you, uh, with something new that you've not learned before or something that you once knew that you need reminding of or possibly something that you want to share with a friend or a colleague or somebody that you work with. So, that's the deal. Okay, there's going to be a quick introduction and then three acts. Act one is called people are hard. Who **[02:35]** works with people? Yeah. Anyone not work with people? [laughter] One. Um, working with people is difficult. Like we work with computers as well and it's surprisingly easy kind of relatively to get computers to do what you want them to do. Getting people to do what you want them to do is actually quite hard. I know because I'm a parent of a teenager. Um act uh so act one is lessons I've learned about teamwork collaboration communication stuff like that working with people. Act **[03:06]** two is called coding is hard because actually the technical stuff that we do is also quite difficult and I've learned a few things about that over the last 25 years. Act three is called you are um and I wanted a better word but the best word I could come up with was squishy. Don't take this the wrong way. This is like an abbreviation for you are a soft squishy human being bag of fragile human cells and you need to look after yourself. So this is my self-care tips for people who uh do very sedentary **[03:38]** jobs and get stressed from time to time. So that's what we're going to try and do. Quick introduction. Haven't said who I am. I am Ross and I currently work for WP Engine and I got there via Delicious Brains who you may have heard of. They develop amazing plugins. Uh WP Engine have a standover there where you can uh go and enter a competition to win a PS5. So hopefully that's my uh my work duties out of the way. Um but I've had a this **[04:08]** long career and it's not always been in WordPress unlike Ryan who's been doing WordPress for how long was it? >> 21 years. You've been working nearly as long as me, but it's all been WordPress. Um I started off working in the aerospace industry doing safety critical software development and that's a whole different world to what we do now uh what I do now. Um and it came with a whole bunch of different needs and requirements and ways of building and testing software. I then worked for eight years in a big hosting company. **[04:40]** I've done 11 years of freelancing with WordPress. Um lots of different things in different bits of the tech industry. So that's me. How are we doing? Right. Oh, that was a long intro. Right. People are hard. Um, when I say this, I'm not referring to any specific people. And all of these lessons have been learned from like they're in here because I've experienced them multiple times throughout my career. As they say in the films, any similarity with real events or characters is purely coincidental. **[05:16]** Lesson one. Why has lesson one disappeared from my slides? Oh, that's right. Because it was don't submit fun talk ideas. Lesson two, opinions are good, but they are just opinions. And I've learned that it's really important to recognize within yourself and within other people when something is an opinion and when it is a fact or a truth. And actually, we live in a world where there are lots of people expressing facts and truths that may not actually be facts or truths. So, we need to just remember that sometimes we hold **[05:48]** opinions too too hard and we need to think about letting them go. And sometimes other people that we hear from aren't actually telling you a fact. They're telling you an opinion. And I'm very aware of the hypocrisy of this talk, which is 25 lessons, all of which are really my opinions and beliefs. So, you can in your head prefix each of my slides with I think, I believe, or in my experience. Also, opinions can be changed. This is not saying that you can just go out and **[06:20]** start telling people to change their opinions about things. Um, in fact, quite the opposite. You should start by thinking about how your own opinions can be changed because the way to change opinions is that you go and you you seek understanding of why other people hold an opinion and uh the sort of facts or ideas or experiences behind that and come alongside that person from their point of view. They might change your opinion in having that discussion. **[06:50]** We did a piece of work recently where um I started writing a proposal for doing something and I got about halfway through and I'd gone out um being curious, trying to listen and learn about the subject that I was trying to write a proposal about and ended up completely like changing my mind and scrapping the proposal. If we want to change opinions of others or ourselves, sometimes we're in a position where we have authority and experience to be able to do so. In which case, don't just state your opinions at **[07:22]** people. Make sure you back them up with data and with demonstration. I've recently heard a great idea of uh if you want to try getting your team to do something new, run a short experiment that's time bound and if that experiment works, then the thing will probably stick around and if it doesn't work, you'll probably find out quite quickly. Also, opinions can sometimes not be changed. Um, so bear that in mind. Sometimes um your opinion is different to someone else's and that can be okay. **[07:56]** Going to be some real talk in this talk. We're going to address some of the um Tim's looking at his watch. I'm worried. Going to address some of the really difficult uh issues of our world. So, I'd like you to raise your hand if you believe that you know the best way to load a dishwasher. Oh, there are people who don't know the best way to load a dishwasher. Um, what on earth has this got to do with coding? Lesson four, I've called high standards, **[08:27]** low expectations. And there is this quote from James Clear. Life is harder when you expect a lot of the world and little of yourself. And life is easier when you expect a lot of yourself and little of the world. High standards, low expectations. And this is a quote which has really stuck with me and influenced my attitude towards certain things. And this is not again it's not saying that you should just go and uh break the rules in order to do things the way that you want them **[08:57]** to. But having the attitude of I think I know what the right thing is to do here and even though everyone else around me isn't doing it, I'm still going to do the right thing. And bear in mind that you can't always change other people's opinions and accept that and just keep doing the right thing yourself even though other people might not be doing that. It's just a lesson that stuck with me. Lesson five, engineering is a team sport. Has anyone played this game? You know this game? Pico Park this is **[09:29]** called. It's about £7 and it's the most fun you can have with your family um on a computer. The red guy. There's a whole conference talk about the red guy who's like clearly the extrovert who wants to go first everything. Um he's amazing. But we must think of engineering as this team activity. And if you look at team sports, there are different positions and people have different strengths and weaknesses. They um I think got to the end yet. Oh, it looped. Um people have different strengths and weaknesses and they train specifically for their roles. **[10:00]** And quite a lot of the lessons following this in the people section. Um, just to follow on from this idea that we must bear in mind that we're working as a team. We succeed together, we fail together. For lesson six, we're going to move on from that and go to talk about understanding the other people in your team and the roles and positions that they have. Everyone's brain works differently. I kind of started realizing this like properly about six or seven years **[10:31]** ago. 16 personalities is a site that does MyersBriggs um and then gives you some fancy interpretation of it. Um it's actually really good, but these personality tests um they're not necessarily scientific. Sometimes they've been debunked. Sometimes they're unhelpful, but they can be really helpful if you take them. Maybe you will see something of yourself in them. According to 16 personalities, I'm an advocate. And that was really helpful for me because lots of people think I should be a leader. But actually my personality type is not a leader. **[11:03]** It's as like a second in command. I work best when I'm advising somebody else who is actually the leader. We do a thing at work called Clifton Strengths. And with Clifton strengths, uh my number one strength is relator. And it turns out being a relator is quite unusual on a team of software developers. Um so this puts me in a unique role and with some unique skills. um which uh are very different to uh other people that I work with from time to time. **[11:34]** Someone once turned up on my team um and they had this great idea which was to write a personal readme or a user guide for yourself. They brought this with them and I thought it was really good. If you go to manualof.m.me, it's a great site that you can work through a structured set of questions that can help you build out such a document. And it's really worth doing as a structured way of exploring how you work even if you don't then share that with your teammates. But understanding that people's brains work differently and uh what people's strengths and weaknesses are enable you to function better as a **[12:06]** team and do better work. And following that, I've worked with all sorts of people. people from different uh different religions, different places in the world, different cultures, different genders, different ethnicities, and they they've all been amazing. And I think diversity is such an important thing for our industry. These are fairly select statistics, but the links, if you've tapped lesson seven **[12:38]** um on the app, there's loads of links to the original places these came from. But if I came to your business and said you could earn two and a half times higher cash flow per employee, you could be 35% more productive or you could make better decisions 87% of the time. These are all stats about companies who have embraced diversity practices. I'm very aware that I'm straight white guy stood on the stage and so maybe I'm not the most qualified person to be talking about this. I'm still learning how to do diversity and how to talk **[13:08]** about diversity. But here's some ideas. You need diverse leadership within your organization and those leaders need to be promoting the idea of diversity within your organization. That will involve training. A few weeks ago at WP Engine, uh we had our compulsory annual compliance training and I had to do a brilliant course on bias and it was so revealing to me. Um going back to I'm still learning. Uh I learned a lot from doing that piece of training. You need fair hiring. you need fair pay. Um, you **[13:41]** need to create a culture of safety and welcome for everybody and you need to support those people by listening to what they need and understanding how uh you can support them in their work. Finally, on the difficult bit, uh you don't know what's going on with people. So, when people turn up at their desk in the morning, um you don't know what they've been through. Uh, as a parent, um, sometimes I arrive at my desk and it's been like, "Oh, off you go, kids. Have a lovely day. Love you. Bye." Like **[14:13]** this. Um, sometimes I have spent the last half hour trying to find exercise books and bits of PE kit that aren't clean and everything's running late and nobody's had breakfast and you eventually get them out the door and you just need to sit down for 10 minutes with a cup of tea before you can actually go and do anything else to recover from that morning routine. That's a trivial example, but you don't know what's going on with people. So, if someone's not behaving like they normally do, just bear that in mind. Be kind to them. Give them some grace **[14:44]** because you don't know what's going on with them. Gosh, that was heavy. Everyone's gone very quiet. Let's do something a little bit lighter. Did you know you can say nice things? Who's British? Very good. who's just a grumpy software developer. Yeah, I when I started at WP Engine, I started working with a lot of Americans and I'm stereotyping, but they are much more uh outgoing and energetic uh in **[15:15]** their praise of people. Um, and it was a bit cringey at first, but then I got used to it and realized that this is a really important thing. You can say nice things about people's work. If you're doing a code review and someone's done something well, um, you can say, "Hey, this is really good. I like this." Um, if you're having a stand up and someone's done a great piece of work, you can say that was a great job that you did. But also try and remember, be specific because saying great job on its own isn't actually very much. Saying I really like the way that you presented those bullet points to management is a **[15:46]** little bit more specific and useful for that person. And finally, and very much related, feedback is fuel for your work and your career. Learn to give it well by being specific and timely. And there are models for doing this and I've linked some stuff in the notes. Learn to receive it well. Uh learn to only give it when it's been solicited or when it's really urgent or important. Um because people don't always want feedback. They might not be at a point where they're ready to receive it. Learning to give and receive **[16:18]** feedback really critical because we can't grow. We can't uh start doing the right things or keep doing the right things if we don't know what the right things are. That was act one. Oh my goodness, I'm running so late. Where we're going to have to speed through. Coding is hard. Our jobs sat at these computers where we like type these little um characters into these windows. Here's it's really interesting. And sometimes those characters get turned into things that computers can write. Um but often coding **[16:50]** is hard because code is actually in my opinion put that right at the top. uh for humans and specifically it's for other humans that might be you at a later point in time or it might be a completely different human being. Um but this really is we need to think about this because the things that you type yes they get run by a computer but they will be read by other humans. So lesson 11 is to write simple readable and understandable code. This probably sounds obvious um but I'm continually **[17:21]** learning good ways to do this and I had several lessons about this and I decided actually no just go read this book. This is called the base code field guide to writing good code. It's written by a guy from the Laravel community and it's not like one of these really dense academic looking technical coding books. It's about 80 pages of content and it transformed I think for the better the way that I write my code. It's really good. It's linked in the notes. Did you know you can read your own code? **[17:54]** The number of times that I've just before submitting code for review or for deployment just walked away and grabbed a cup of coffee and come back and sat down and gone like who wrote this? I got a nod. I've got a nod. That's good. Um, read your own code before you like do anything with it. You will find bugs. You will find badly named variables. You will find comments that don't make sense. Um, and you can save like whole review cycles by just going and looking um at your own code and updating it to be better. **[18:25]** Lesson 13 is don't be too clever. We can write all sorts of clever bits of code, but if they're not simple, readable, understandable, um, then you know other people might come to it and go, "Huh?" Like when you look at this, anyone see this recently? This code shaped like the moon prints the current moon phase. Anyone tell me how this works? or this one. This is code that prints a clock inside the code that prints the clock inside the code. Amazing stuff. Um, don't be too clever **[18:57]** writing your code. Keep it simple. Keep it readable. Lesson 14. And this is uh like Instagrammable or whatever. So, get your cameras out because this is the clickbait one. Don't fix Who likes fixing bugs? No. No. Don't put your hand. You like fixing bugs. Oh. Don't fix bugs, avoid them. This is interesting. Have you seen how SpaceX build rockets these days? They build loads of rockets and they just smash them into the ground or let them burn up in the sky um with the aim that they can collect some data to make **[19:29]** a better rocket. Back in about 1981, the first space shuttle went into uh went around the Earth and it had been so well engineered, designed, thought about, programmed, built, constructed that um it had people on it. They were happy that this had been engineered well enough that they could put people on it when it first went into space. And like you're not going to write bug-free code, but maybe there's something in this about thinking harder **[20:00]** about requirements, making sure we understand what we're building before we start building it. Running uh tests or writing and running tests using static analysis and llinters, all sorts of stuff that we can do if we just put a little bit time in up front to try and avoid having bugs in the first place so that we don't then have to fix them. Some of you will have seen this before. This is JavaScript. Anyone know what this says? Well, what this gives you back will prints. It does not print I am 25 years old as **[20:32]** you might think. It prints nan years old. And this lesson I'm borrowing from someone here, but this lesson is learn operators deeply. I guarantee if you don't know what operators are, operators are plus Oh, sorry. Do you want that? Go on. operators are plus minus times divide equals and a few other things like the turnary operator and I guarantee that you do not know what these things do and if you do come and talk to me afterwards and I will I will yes um you are amazing um don't trust these things don't assume **[21:03]** that you know what they do uh I'll use some big words operator precedence operator associivity type juggling type casting type coercion they will trip you up do not assume that you know how these things work either learn them deeply or learn to deeply mistrust them. Lesson 16, old things can be good things. Um, and this is like I work on the WP Migrate product which is this like decade old plug-in that moves WordPress sites from one to another and **[21:35]** been working on the product for a year and it is incredible how much historical knowledge is built into this plug-in. Clever ways of doing things. um or bug fixes that have come up over the years, edge cases that have been encountered and worked around. Um it's an old thing, but actually it's a really good thing because it's old. And I think in WordPress we put these little notices, don't we, on plugins that say this is bad because it's not been updated for three years. But we don't on a new plug-in put a banner that says, **[22:07]** "Hey, this is brand new. It might contain loads of bugs and be feature incomplete." Like, we don't do that. We think of new things as good and old things as bad. New things can be good. Use them. Experiment with them. But old things can be good, too. And I think sometimes we just need to flip that script. Lesson 17 is look outside your bubble. John's still here. John talked a lot about this and it was really, really cool how he talked about it. Um, I think WordPress can be quite insular and I've benefited so much by looking at the Laravel ecosystem, uh, building some **[22:37]** games and doing stuff like that. There's a lot of tooling and information out there and tools and techniques that are really good to go and seek out and then bring back into the WordPress world and make your work better. Look outside your bubble. I said there'd be some some more real talk. We need to There's a thing that is incredibly important that's very very undervalued that we all if you're a developer you use multiple times every day and we need to just **[23:09]** elevate it a little bit and celebrate it. It's the semicolon. What a beautiful thing. Um some people, would you believe this? Some people don't like this beautiful thing. amazing. They don't want to put them in their code. Um, lesson 18 is that standards are good. We can discuss whether or not semicolons look good on the end of lines or have any benefit. Um, we can discuss tabs and spaces and all that stuff, but actually I've come **[23:40]** to learn that standards are good, but just pick a standard and automate it out of the way. Just use the amazing tools. Is Juliet here yet? No, I don't think so. Juliet is speaking later. She builds PHP uh code sniffer and uh the WordPress P uh WordPress PHP coding standards. She looks after the rule sets and PHP compatibility. Uh she's desperately underfunded. Go and sponsor her, support her, say hi to her. She's a fascinating person. She does amazing work. Um standards are good. Pick a standard, automate it away, just **[24:11]** get on with your life. Here's the thing. What do you think? I I asked uh asked myself this question. What's the oldest piece of software in my house? Any guesses of every snooze? So, this thing, this is the original Nintendo Game Boy. Still has Tetris in the back. This runs 35y old software that has never been **[24:42]** updated and as far as I can tell is completely free of bugs. Amazing. What if software could be finished? This lesson almost didn't make it in. Um, but it kept coming back to haunt me. It wanted to be in the talk. And you're never going to write finished software. Um, well, no, actually, you can. I've written some finished software. Your business won't want you to write finished software. It's probably not good for business. But I like the idea **[25:12]** of writing finished software. And I like thinking what are the things we'd have to do for software to be finished like having few dependencies or no dependencies. Um making sure that we apply the lessons about having fewer bugs. Um there's all sorts of things that we might think about when we think how could software be finished. So I don't present it to you as an end goal. I present it to you as an idea to think about. Coding is hard. **[25:46]** Act three. You are squishy. And I do mean it in the nicest possible way. Um, you are just this sack of cells and uh you need looking after. This might not sound like a lesson about self-care, which these lessons are. Um, but lesson 20 is write things down to forget them. Another great quote that I've heard is writing things down isn't just for remembering things, it's for forgetting them. And writing things down is actually a really, really, really important skill. We should write things **[26:18]** down to share knowledge with our future selves and other people. That institutional knowledge about our code. Um, there's lots of good reasons why writing is a good skill and we should practice it often. But sometimes I'm stuck in my head. Um, I can't get to sleep because there's ideas buzzing around. I can't focus on my work because I'm thinking about seven other things. And it's really helpful for me to just write them down. And there's this magic thing that happens, which is when I write them down, they sort of disappear **[26:48]** from my head. And everyone's brains work differently. So, this might not work for you, but I find it's a really good tool for getting sleep and focus. And I offer it to you as a as a suggestion. Did you know you can ask people to mentor you? I hope my friend Jen agrees with this. Um, Jen has been giving me some help uh and has been brilliant. Um, I learned this recently. I watched some LinkedIn training and it said you can **[27:19]** you can go and ask for mentors. I was like what can you? And since I watched that I think four different people have given me four different kinds of mentoring in the world. And I think this is true. I'm happy to be corrected, but I think the worst thing that can happen when you ask someone to mentor you is that they say no for whatever reason and they're incredibly flattered that you asked them. And that's a good thing. You can just do this. This is great. Do it. Find someone you respect and admire that you think can help you in your career and ask them **[27:50]** to mentor you. Lesson 22 is move around. Probably sounds obvious, but it's really easy for us just to sit at our desks for hours on end. I got RSI quite early in my career. My wrists would not stop like fizzing and hurting. I took painkillers. I did physio. But the only thing that helped and it's not come back since I started doing it is taking really frequent breaks at least once an hour. And not just like breaks and scroll your phone. Move around at least once an hour. If I'm not in meetings, I will get **[28:22]** up and I will actually move around. I've got some small bits of gym equipment in my office, just move, do all sorts of crazy stuff. Um, bend your body, move your body, go for a walk to get a cup of coffee somewhere. Um, frequent breaks and sit stand desks. I have a sitst stand desk that goes up and down. And the advice around those, as far as I can tell, is you shouldn't sit or stand for longer than half an hour at a time. So these are things where you don't stand because standing is good for you. You stand for a while and then you sit for a while and then you stand for a **[28:53]** while and you keep your body moving. Your body wants to move. Move it. Look after it. You will uh you will thank me later in life. Lesson 23 is if you can buy good stuff. I used to have like a 15 pound mice mice mouse and I thought it was good enough. Um, and then I bought like a 60 pound mouse because someone had recommended it. And actually, this thing's flipping amazing. I love my 60 pound mouse. I bought like three of them. I've got one in my bag. **[29:24]** I've got another one like in my drawer just as a backup because you can't buy them anymore. Um, chairs, desks, uh, what else? Monitors, keyboards. You can go over the top. You can spend like400 on a keyboard. You don't need to do that. But maybe think about leveling up your equipment or get your employer to level up your equipment if you can. Invest in yourself. It's really, really super important to do. One final bit of real talk. We've talked about people being hard. **[29:59]** We've talked about coding being hard. And now I want to tell you about the most difficult part of my job. typing things accurately onto a keyboard. Anyone use PHP? Anyone ever typed this? Anyone live in a an English county? You know, they put the R next to the T key, didn't they? Can this go in? Is this all **[30:30]** right? In my job, I have to type this like so many times every day and it's so hard to type. And then this just so frustrating. Type less, smile more. Um, invest in learning and tooling that removes these little micro frictions from your day and you will be happier. Um, text expansion is built into loads of tools these days. Clipboard history is **[31:01]** an absolute gamecher. Uh when I do multicursor editing in my editor or IDE, I feel like I have this superpower that no one else in the world has. Type less, smile more, learn those tools, get those tools, set them up, and remove frustration from your day. Finally, I got my 10-minute notice, so I'm on time. I'm doing all right. You are awesome. Um but the lesson isn't that you are awesome. The lesson is that you need to remember that you are awesome. And there **[31:32]** was a great video about six years ago from a guy who was in the WordPress community at the time. I can't track him down anymore. Um about keeping a thing called an awesome log. And this is like a private journal where you record nice things that people say about you. So that when you're not being a good friend to yourself and you're being down on yourself, you can look back at the nice things that people have se have said about you and the work that you do and remember that actually you can do this. And I refer to this often. I also keep **[32:03]** an achievement log. So I evolved this idea into one where I also keep a list of achievements and specific things that I've done at work. preferably with like metrics and statistics about the difference that they made. Um so that when I come to like apply for a job, update my CV, um go to an interview, I've got some of those facts and stats at hand because you won't remember them in six months time. So get into the habit of writing them down. Um and then you can just pull them up when you need them, which you will at some point. **[32:36]** You you are squishy in the nicest possible way. I have presented you I don't know what the time is. My clock went weird. Um I presented you 25 lessons from my career. Or did I? Maybe I only presented one lesson. Brian, would you have would you have done this? Would you have done one lesson from 25 years? I don't think you would. **[33:09]** So many of the things I've said can be wrapped up in this one thing. Be open-minded. Be open-minded about understanding the people that you work with, how they work, how you can work better together. Be open-minded about the technology that you use and how you use it. Don't get stuck in old ways. Go out and find new ways of working. and be open-minded about the fact that you are this squishy bag of fragile human cells that needs looking after and all of the **[33:41]** many ways that exist in the world now to take care of yourself. In my experience, open-minded developers are more productive, they're happier, and they're more valuable. So hopefully, are we now seeing a list? Anyone with the page open? Are we now seeing a list of talk topics? Has it unlocked? Yes. Come on. Um, you can now go and uh get your own custom show notes. And I wonder what's **[34:12]** the one thing that you're going to take with you from today and take into next week to learn or to share. Thank you. uh at the back at the stand at the back if you don't remember from the start of the talk is WP Engine. They uh there's a competition to win a PS5. Uh this is me and thank