25 Lessons  ## Metadata - Author: [[forwp.dev]] - Full Title: 25 Lessons - Category: #articles - Document Note: --- tags: - #wordpress - #developer-advocacy - #open-source Author: Ross Wintle Source: forwp.dev Reference: https://25.forwp.dev/ date created: 2025-09-25 00:00 --- # Title: 25 Lessons from 25 Years in 25 Minutes (LoopConf 2025) — Notes ## 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-deib-assessment) - 🔗 [✅ Logical validity](#-logical-validity) - 🔗 [🔍 DARVO Analysis Prompt](#-darvo-analysis-prompt) - 🔗 [🔍 SEO Evaluation](#-seo-evaluation) - 🔗 [🎯 Conclusion](#-conclusion) ### References: Include a list of sources consulted and cited in the article. ## 📝 Summary: A concise, practical set of 25 lessons distilled from Ross Wintle’s career in engineering, management, and WordPress. Themes: humility around opinions, communication, feedback, standards, testing, inclusivity, ergonomics/productivity, and sustainable craft. Emphasis on team dynamics, actionable habits, and balanced skepticism toward novelty vs. mature tools. ## 📖 Main Content: - Opinions vs facts; cultivate curiosity, evidence, and reversible experiments. - High standards, low expectations: do the right thing consistently without entitlement. - Engineering as a team sport: communication, collaboration, management literacy. - Diversity as strength: better problem-solving, user empathy, and culture. - Practice kindness and specificity in praise and feedback; learn to solicit/give. - Code quality habits: read your own code, avoid over-cleverness, prevent bugs. - Embrace standards, static analysis, tests, and linting to reduce toil. - Learn operators deeply; know precedence/coercion pitfalls and mitigate. - Value old/mature tech; beware novelty churn. - Look outside your bubble; import tools/practices from adjacent ecosystems. - Software can be “finished”; small/static apps; write to forget and to think. - Mentorship: ask for it; movement/ergonomics; invest in quality gear if possible. - Reduce micro-friction: snippets, launchers, hyper-keys, automations. - Maintain an “Awesome/Achievement Log” to track impact and morale. ### 🗒️ Notes - 1. Don’t submit “fun” talk ideas; take talks seriously; coaching helps (Jill Binder). - 2. Opinions are good but not facts; favor open-ended questions; curiosity over adversity. - 3. Opinions can change; use data and demonstrations; run time-limited tests with rollback. - 4. High standards, low expectations (James Clear); keep doing the right thing. - 5. Engineering is a team sport; communication and management literacy matter. - 6. Diversity is strength; implement inclusive hiring, pay equity, training, safe culture. - 7. You don’t know what’s going on with people; give grace. - 8. Say nice things; be specific in praise. - 9. Feedback is fuel; seek/give specific, solicited feedback; Radical Candor concepts. - 10. Read your own code before review/deploy; you’ll catch issues. - 11. Don’t be too clever; optimize for clarity over terse tricks. - 12. Don’t fix bugs—avoid them; requirements, static analysis, tests, linting, standards. - 13. Standards are good; automate style to avoid debate; use PHPCS/Prettier/WordPress rules. - 14. Learn operators deeply; beware precedence/associativity/coercion; mitigate with linting and parentheses. - 15. Old things can be good; mature tools handle edge cases; WordPress/PHP longevity. - 16. Novelty trap critique; tool churn creates new problems. - 17. Look outside your bubble; borrow from Laravel, JS, Go, etc.; tools like Tinkerwell, Ray, AlpineJS. - 18. Software can be finished; small/static app manifesto. - 19. Write to forget; externalize memory; documentation builds institutional knowledge. - 20. Ask for mentorship; be proactive. - 21. Move around; alternate sit/stand; Pomodoro micro-workouts. - 22. Buy good gear if possible; ergonomics and reliability are personal. - 23. Type less, smile more; remove micro-friction with snippets/launchers/shortcuts. - 24. Command-line and browser workflow resources; Wizard Zines, Efficient Linux, bookmarklets. - 25. You are awesome; keep an Achievement Log; private, impact-focused. ## 📖 References: - Radical Candor overview on YouTube - WordPress Coding Standards; PHP CodeSniffer (maintained by Juliette) - PHPStan proposal discussion for WordPress - Smashing Magazine articles on documentation and modern web dev churn - Carl Alexander on testing in WordPress - Prettier “Why Prettier?” and option philosophy - BBC podcasts: Space Shuttle; standing desks - Tinkerwell, Ray, AlpineJS; Basecode Field Guide - Wizard Zines; Efficient Linux at the Command Line ## 🗣️ Paraphrase: - Original idea: “High standards, low expectations… Life is easier when you expect a lot of yourself and little of the world.” Paraphrase: Hold yourself to a high bar, but don’t rely on others or the universe to do the same. Focus on your own craft and consistency; release expectations that the environment will conform. - Original idea: “Don’t fix bugs. Avoid them… requirements, static analysis, testing, linting, code standards.” Paraphrase: Prevent defects upstream. Clarify what you’re building, enforce correctness with analyzers and linters, and validate behavior with tests. Shared standards reduce ambiguity and rework. ## 📰 Newsletter: This week in WordPress and Open Source: Learning, shipping, and thriving. We’re spotlighting Ross Wintle’s “25 Lessons from 25 Years,” a rapid-fire masterclass in sustainable dev: treat opinions as hypotheses, run reversible experiments, keep standards automated, and prefer clarity over cleverness. For learners: revisit testing basics in WordPress (see Carl Alexander’s primers) and explore static analysis with PHPStan alongside WordPress Coding Standards via PHPCS. Community highlight: diversity isn’t a checkbox—it’s a performance multiplier. Audit your hiring, pay practices, and onboarding to widen the contributor pipeline. Tools we’re loving: Tinkerwell, Ray, and AlpineJS to sharpen your debugging and UI edges; plus micro-friction slayers like snippets, command palettes, and hyper-keys. Health check: alternate sit/stand every 30 minutes and sprinkle Pomodoro “micro-workouts.” Pro tip: keep an Achievement Log—future you (and your CV) will thank you. Links: WordPress Coding Standards; Prettier philosophy; Radical Candor overview; BBC on standing desks. ## ✅ Action Items: - For advocacy: Frame “standards are good” as a contributor-experience win; propose PHPCS + WordPress rules + Prettier defaults in contributor guides with pre-commit hooks. - For engagement: Run a “feedback is fuel” workshop using Radical Candor principles; create praise templates emphasizing specificity. - For education: Build a short course on “Avoiding Bugs by Design” covering requirements refinement, static analysis, and unit testing in WP (PHPUnit) with examples. - For OSPO trajectory: Draft a policy on coding standards, security scanning, and documentation (“write to forget” principle) to institutionalize knowledge and reduce risk. - For DEIB: Publish an inclusive hiring checklist (structured interviews, pay transparency, bias mitigation) and offer mentorship pairing (“ask for mentorship” normalized). - For sustainability: Pilot “finished software” criteria for internal tools; prefer small/static deliverables where viable. - For productivity enablement: Provide team licenses for launchers (Raycast/Alfred), snippet tools, and training on keyboard-driven workflows. - Alignment: These actions advance open-source health (quality gates), grow contributors (mentorship, inclusive practices), and strengthen transparency (docs, standards), directly supporting OSPO leadership goals. ## 🧪 Hypotheses: - H1: Automating c - Summary: 25 Lessons from 25 Years in 25 Minutes - Ross Wintle - LoopConf 2025 - URL: https://25.forwp.dev/ 1. ##### Don't submit "fun" talk ideas to conferences. Are you really interested in this lesson? Actually, speaking at LoopConf has been excellent. Brian has been a really great host and organiser. And I'm really glad I get to share some of what I have learned with you. Thank you for being part of my audience. If you have submitted a "fun" talk to a conference (or any talk, for that matter), I can highly recommend [Jill Binder](https://speaktechconfidently.com/)'s services. She is a public speaking coach who helps tech professionals with public speaking. She was a huge help honing this talk to make it the best it could be. 2. ##### Opinions are good, but they are just opinions. Learn to recognise where things are opinions and not facts. Both in yourself and in others. Links/resources: * "Ask open-ended questions instead of making strong or opinionated statements." - there are many great tips in [kind.engineering](https://kind.engineering/#async-comms). * "Approach different opinions with curiosity rather than adversity." - says [Felix Arntz](https://felix-arntz.me/blog/10-lessons-from-10-years-of-contributing-to-wordpress-core/#adapt-well) * [Some useful phrases as alternative to "I think" or "I believe"](https://cambridgeclassroomchronicles.wordpress.com/2025/03/12/sharing-your-opinion-alternatives-to-i-think/) - Useful stuff from a Cambridge exam prep teacher. 3. ##### Opinions can be changed! IMPORTANT NOTE: Do NOT take this as an invitation to go around trying to get everyone to think the same as you! This lesson is as much about you being open to changing your own opinions as it is about how you change the opinions of others. Changing opinions of others starts with understanding where those opinions come from. Be curious. Ask. Seek to understand the other side. If you really are in a position to influence people, there are two main things I do to try to change opinions: * Using data: What evidence is there that supports your opinion? Is there someone more experienced that knows more than you that can contribute? I've often changed my own opinion as I've gone seeking evidence for a belief I've held. Be prepared for that! * Using demonstration: Run a time-limited test with the option to roll back - sometimes your specific context can influence the validity of a given tool or process. Or model the behaviour or technique and then talk about the changes/results. I'm doing it right now as I write this... researching how to change opinions. Seeking knowledge and experience that backs up my own "lesson" that I want to teach. I hope I come out still thinking "Opinions can be changed!!" Links/resources: * "I didn't comment on the actual code or how horrible it was. I asked how I could learn from the code, because I didn't understand it." - [The psychology of offering developers programming advice](https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/programming-advice-developers-tips-best-practices) 4. ##### High standards, low expectations. Just a James Clear quote that really got me thinking about doing a good thing, even when others aren't doing that good thing. I found it really helpful and apply it a lot in both life and work. > Life is harder when you expect a lot of the world and little of yourself. Life is easier when you expect a lot of yourself and little of the world. High standards, low expectations. > > * Load the dishwasher right. * Pick up that sock, or put that shoe away. * Join in with that litter pick at your local park. * Write that helpful comment. * Ask the awkward question that everyone is thinking. I'm not saying you should disobey the rules to do things your own way because the rules are wrong. I'm encouraging you to keep doing the right thing, even when others aren't being as diligent. 5. ##### Engineering is a team sport. There are many good books and articles about being a good engineer. Links: * The [The Staff Engineers Path](https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/) is a great resource on levelling up as a developer and talks a lot about communication. * Read about [The Worst Programmer I Know](https://dannorth.net/blog/the-worst-programmer/): "Tim wasn't delivering software; Tim was delivering a team that was delivering software." * There's some great stuff on communication in remote work situations in [this Smashing Magazine article](https://www.smashingmagazine.com/2021/02/improve-team-communication-age-remote-work) * The book [Engineering Management for the the Rest of Us](https://www.engmanagement.dev/) and Julia Evans's [Help! I have a manager!](https://wizardzines.com/zines/manager/) are also great guides both for being a manager, and for understanding your manager's job. Oh, and the silly little cooperative game I showed a video of? That was Pico Park, it's extremely good value for money and has made my family laugh and argue a lot! 6. ##### Everyone's brain works differently. Links: * We did [Clifton Strengths](https://www.gallup.com/cliftonstrengths/) at work and found it very helpful - but it may be expensive. * Make your own personal README / User Guide at [Manual of Me](https://www.manualof.me/) 7. ##### Diversity really is a strength (and a joy). I quoted some stats in the talk, and yes, they were selective and were removed of some of the detail and context, but these were real numbers from the reports linked below. In general: * Different experiences help us consider more people as our users. * Different ways of thinking give us better problem solving ability. * And exploring different cultures can make work more interesting. How can you achieve this? * Through having a diverse team of leaders. * By having people take a lead on the issue of diversity. * Leading on diversity will include providing training. * By ensuring you have fair hiring practices. * By providing fair and equal pay. * By creating a safe and equitable working environment for all people. * By supporting staff when they need it. * By listening to what they need and taking them seriously. This is a huge topic. I can't possibly do it justice here. But I hope you take the nudge to find out more. 8. ##### You don't know what's going on with people. I think this lesson just speaks for itself. I could relay stories of my own, but they are too personal to share in most cases. You could search the internet but it's full of click-baity listicles which may or not be true. Just... if someone you work with isn't being themself... give them grace and kindness. You don't know what's going on with them. 9. ##### Say nice things (about people's work!) It *really* helps to be specific about what is nice. "Great work!" on repeat can lose it's meaning. Try something like: > "I really like how you write up the pros and cons in that proposal so succintly." "This explanatory comment will really help us in the future." > > Links: * [A great podcast segment](https://pca.st/episode/f7f65c87-d126-467e-b685-7103a8e69b16?t=1177.0) talking about how we've forgotten we can just "like things". 10. ##### Feedback is fuel. The main points here are: 1. We can only grow if we know what we are doing well (so we can keep doing it) and what we need to do differently. If a team is good at feedback, then we should not be afraid of it. But that is not always the case. And it's not easy for everyone. 2. Learning to give and receive feedback well is important. Learn about it!! 3. *Specific* feedback is especially helpful. See lesson 9 for examples of that. 4. Try to only give "constructive" feedback if it has been solicited. Links: * We get [Radical Candor](https://www.radicalcandor.com/) training at WP Engine. I like the ideas in it, but it's still hard to do in practice. There is [a good overview on YouTube](https://www.youtube.com/watch?v=f-Tcr0T9Tyw). * There is [a ton of good stuff on LeadDev](https://leaddev.com/search/feedback), but this article on how to get feedback is a good one for all of us. 11. ##### Read this (free) book. [The Basecode Field Guide](https://basecodefieldguide.com/) is a free, short, eBook with lots of great tips that have been a huge (and in my opinion, positive) influence on my coding style. 12. ##### Read your own code. Before you submit code for review or deployment, take a quick break, grab a drink, then read your own code. Every single time I do this I find bugs to fix, comments that don't make sense, or code that could be simplified. And if I fix it, I could save a re-review or a re-deployment. Or worse! I have no bookmarked resources for this. And searching brings up nothing relevant. This one is straight out of my own head and experience. Perhaps that means it's not a very good idea? I don't know. I try do it and it's always helpful. 13. ##### Don't be too clever. I think this lesson is partly inspired by several chapters from The Basecode Field Guide (see lesson 11). But it's also just from experience. Sometimes an if...then...else statement is more easier to understand than a ternary. Sometimes, yes, you can condense 7 lines into one very clever line. But does it make sense? And does doing so add value? The examples I gave in the talk were clearly extreme. Links: * [The Best Programmers I Know](https://endler.dev/2025/best-programmers/#keep-it-simple) references this idea. 14. ##### Don't fix bugs. Avoid them. In the talk I referenced the way that [SpaceX are building space rockets like a startup builds software](https://www.scientificamerican.com/article/why-do-spacexs-starships-keep-exploding/), as opposed to the Space Shuttle, which made it's very first trip to space and back with humans on board. This is nicely documented in [the recent BBC podcast series on the Space Shuttle](https://www.bbc.co.uk/programmes/w3ct80bk). As techniques I will have referenced: * Doing better [requirements analysis](https://www.browserstack.com/guide/requirement-analysis) - basically, putting more thought in up front to what you are about to build. * Static Analysis, which I wrote about on [the Delicious Brains blog](https://deliciousbrains.com/php-static-code-analysis/) a while back. PHPStan was [recently proposed for WordPress core development](https://make.wordpress.org/core/2025/07/11/proposal-phpstan-in-the-wordpress-core-development-workflow/) and the arguments for it are well stated there. * Testing: + Carl Alexander has some older, but good articles on testing in WordPress - see [here](https://carlalexander.ca/introduction-wordpress-unit-testing/), [here](https://carlalexander.ca/how-to-start-unit-testing-wordpress-code/) and [here](https://carlalexander.ca/introduction-wordpress-acceptance-testing/). + I know of [courses for Laravel testing](https://spatie.be/products/testing-laravel), but I don't know of so much comprehensive material on it in the WordPress ecosystem. + My own testing experience (in web development at least) has very much been in the back-end, PHP side of WordPress. You will have to locate information on JavaScript unit testing yourself. There is lots of help around and several mature tools for doing this. * Linting and code standards: + My fellow speaker at LoopConf, Juliette, maintains [PHP CodeSniffer](https://github.com/PHPCSStandards/PHP_CodeSniffer/) tool and the [WordPress rules for it](https://github.com/WordPress/WordPress-Coding-Standards). [SPONSOR HER](https://opencollective.com/php_codesniffer)! + [wpbestpractices.dev](https://wpbestpractices.dev/development-setup/wordpress-coding-standards/) has a great overview of why you should do this an how. + [The WordPress Code Standards](https://developer.wordpress.org/coding-standards/) are well documented and are a good starting point for both PHP and JavaScript, as well as CSS and HTML. + The "Prettier" formatter for JavaScript has a great "[Why Prettier?](https://prettier.io/docs/why-prettier)" page, and their [option philosophy](https://prettier.io/docs/option-philosophy) is an interesting read too. 15. ##### Learn operators deeply. I'd love to recommend another talk of mine: [I wrote some code - you won't believe what happened next](https://vimeo.com/463988477) - the good recording of this was lost, so this low-quality version from the live feed is all that I have. The three things that often trip people up are: * Operator precedence - the order that operators are evaluated in when multiple different operators are used * Operator associativity - the order that operators are evaluated in when the same operator is used * Type juggling/coercion It's actually nearly impossible to learn these completely. So I encourage you to: * understand that they are "a thing" * learn to recognise when they might be an issue (beware complex calculations with lots of different operators and variable types) * learn how to mitigate issues (linting, static analysis, and the use of parenthesis to ensure things happen in the order you want them to) To try and convince you that operators are difficult I suggest looking up: 16. ##### Old things can be good things. This lesson is that we often write off old things as bad, and hail new things as good. And perhaps we should be more nuanced in our thinking. WordPress plugins that haven't had an update for several years get a warning on them. But they may just be "done" (see lesson 19). They could still work just fine. They may be better than a newer plugin? Why don't brand new plugins have a warning: "Caution: This plugin is new and probably contains bugs and lacks important features."? I work on [WP Migrate](https://deliciousbrains.com/wp-migrate-db-pro/?utm_source=loopconf&utm_medium=presentation&utm_campaign=developer-conference&utm_content=tools-for-developers) and it's a superb product *precisely because it has been around so long*. It has considered so many failure modes and edge cases. One does not just build a WordPress plugin like this it takes time. I'm not saying new things are bad. They are fun and exciting. But I think we ignore old, stable, mature technology too often. Links: * [PHP wasn't dead ten years ago](https://24daysindecember.net/2015/12/25/php-is-dead/) and is possibly [having a bit of a renaissance](https://www.mux.com/blog/php-is-the-new-javascript). It continues to be great and power a huge portion of the web. * [WordPress is 22 years old](https://wordpress.org/news/2003/05/wordpress-now-available/) and, sure, it has baggage. But can we agree that it's good? * "With each new framework or library, a new problem crops up, and time-starved developers spend months developing a new tool to solve that problem" - [This Smashing Magazine article](https://www.smashingmagazine.com/2024/02/web-development-getting-too-complex/) articulates a lot of where I think we have got to with modern web development. 17. ##### Look outside your bubble. There is huge value to be gained by looking around at other tech ecosystems and communities. As a back-end WordPress developer who enjoys PHP, the Laravel framework is very close to us and accessible for us, but also has a lot of very different ideas and tools. But if it's Laravel, or any of the JavaScript ecosystems, or Go, or Rust, or Zig, or Python or the PICO-8 "fantasy console" or the Godot game engine, there is likely something you can learn and bring back to your career in WordPress. In particular, I've found the following things useful in my WordPress work: * [Tinkerwell](https://tinkerwell.app/) and [Ray](https://spatie.be/products/ray) are excellent tools for development and debugging. * The Basecode Field Guide (see lesson 11) * [AlpineJS](https://alpinejs.dev/), which is my favourite small, reactive JavaScript library * Lots of learning about [composer packages](https://spatie.be/products/laravel-package-training) and object-oriented programming and [testing](https://course.testdrivenlaravel.com/) and [static analysis](https://phpstan.org/) and [security](https://securinglaravel.com/) (But see [Tim Nash's course](https://wpsecurity101.com/), which is more relevant here) and [design](https://radicaldesigncourse.com/) who knows what else. * I probably wouldn't have found resources for helping me make my [editor](https://makevscodeawesome.com/) / [IDE](https://masteringphpstorm.com/) clean and fast and easy to use. And finally, for a while, I was writing about this whole topic in a mailing list I called "[Beyond WP](https://beyond-wp.com/)". Maybe this will come back some day? No promises. 18. ##### Standards (any standards!) are good. The idea here is that coding standards *do* matter. But that long discussions/debates about them is not normally time spent well. Decide on a code style, and automate it away with tooling so that you never have to think about it. This speeds up development and review, and eliminates further discussion. Links: * For some "philosophy" on this, The "Prettier" formatter for JavaScript has a great "[Why Prettier?](https://prettier.io/docs/why-prettier)" page, and their [option philosophy](https://prettier.io/docs/option-philosophy) is an interesting read too. * My fellow speaker at LoopConf, Juliette, maintains [PHP CodeSniffer](https://github.com/PHPCSStandards/PHP_CodeSniffer/) tool and the [WordPress rules for it](https://github.com/WordPress/WordPress-Coding-Standards). [SPONSOR HER](https://opencollective.com/php_codesniffer)! * [wpbestpractices.dev](https://wpbestpractices.dev/development-setup/wordpress-coding-standards/) has a great overview of why you should do this an how. * [The WordPress Code Standards](https://developer.wordpress.org/coding-standards/) are well documented and are a good starting point for both PHP and JavaScript, as well as CSS and HTML. 19. ##### Software can be finished. Links: * A lot of my thinking on this is wrapped up in my "[manifesto for small, static, web apps](https://rosswintle.uk/2024/02/a-manifesto-for-small-static-web-apps/)". And yes, this site follows those principles. It could be considered "finished". 20. ##### Write things down to forget them. The source quote is: "Writing things down isn't just for remembering things. It's for forgetting them.", but I don't have the source. But is that right? Well... writing things down can help you remember things: * [A (very academic) study](https://www.openread.academy/en/paper/reading?corpusId=503252214) into whether taking handwritten notes is better than taking digital notes for memory and recollection. But my point is that holding things in your head is a bad idea. Other links on writing: * This [Smashing Magazine article](https://www.smashingmagazine.com/2021/02/improve-team-communication-age-remote-work) has some great stuff about documentation and institutional knowledge. * "Writing is the process by which you realise that you do not understand what you are talking about" is a quote by Shane Parrish from his article ["Writing to Think"](https://fs.blog/writing-to-think/) 21. ##### Ask people to mentor you. Sadly these links are (paywalled) from LinkedIn Learning, where I was studying how to be a good mentor and mentee. They don't quite say "Ask people to mentor you.", but that was one of the things I took away from it. 22. ##### Move around. Links: * [There is an excellent BBC Podcast about the pros and cons of standing desks](https://www.bbc.co.uk/programmes/m002gg75) - this suggests you should only sit or stand for 30 minutes at a time. Alternate if you can. * [My Ikea (UK) Mittzon sit-stand desk](https://www.ikea.com/gb/en/p/mittzon-desk-sit-stand-electric-white-s29529958/) * I use "Pomodoro" breaks, when I can, to stand up, walk, move around, and use simple gym equipment for "micro-workouts". [Pomofocus](https://pomofocus.io/) is an excellent, free, ad-free, web-based Pomodoro timer. But I mostly use the one built in to [the TickTick todo app](https://ticktick.com/). 23. ##### Buy good stuff (if you can). Not much to say here, and what constitutes high-quality, long-lasting, ergonomic equipment is very personal. But I'll link some of the equipment I use: * [My Ikea (UK) Mittzon sit-stand desk](https://www.ikea.com/gb/en/p/mittzon-desk-sit-stand-electric-white-s29529958/) * I alternate between a Logitech MX Master mouse (not quite [this one](https://www.logitech.com/en-gb/shop/p/mx-master-3s.910-006559), but similar - you can usually get them on sale somewhere) and an [MX Vertical](https://www.logitech.com/en-gb/shop/p/mx-vertical-ergonomic-mouse.910-005448). * If you want something cheaper, I also love the [M705 Marathon Mouse](https://www.logitech.com/en-gb/shop/p/m705-wireless-mouse.910-001949) (I honestly thought they had stopped making these) * I got my chair free from an office clearout locally. I have no idea what make or model it is. * I have [a 27" Dell 4K monitor](https://www.dell.com/en-uk/shop/dell-27-4k-usb-c-hub-monitor-p2723qe/apd/210-bdfz/monitors-monitor-accessories). Simple and not too big, but excellent build quality. I love it. 24. ##### Type less, smile more. Honestly. Learn how to and invest time occasionally in eliminating "micro friction" - it saves you time in the long run and makes you feel powerful!!! But what works is, again, different for everyone. Geneal tools and techniques for this: * Autocomplete/text expanding/snippets * Clipboard history * Terminal/shell history, autocomplete, aliases, etc. (efficient command line eBook) * Keyboard shortcuts and "hyper-keys" * Command palettes * Shell scripts (Wizard Zine) * Browser Bookmarklets * Multi-cursor editing Specific tools (these are very MacOS-focussed - sorry!): * MacOS Spotlight is worth learning. It's built in and free. In the new MacOS Tahoe it has some additional powers like Clipboard history. * I use [Alfred](https://www.alfredapp.com/) as my launcher/command palette, but it also has text completion and snippets, clipboard history and lots of tools for custom commands and automation. * Many folks use [Raycast](https://www.raycast.com/) instead of Alfred, but I never graduated to it. * I've written up my use of "Hyper Keys", a StreamDeck and [the R-cmd app on my blog](https://rosswintle.uk/2022/09/minimalism-shortcuts-and-not-getting-distracted/). Super nerds can dive into ["How to train your keyboard"](https://tighten.com/insights/how-to-train-your-keyboard/). * If you like this kind of thing, I made [Turbo Admin](https://turbo-admin.com/) for WordPress! * I've not read it yet, but [Efficient Linux at the Command Line](https://www.oreilly.com/library/view/efficient-linux-at/9781098113391/) is supposedly a great resource for optimising you command-line skills. * Learning the command line and shell (and DNS, and Git, and...) from [Wizard Zines](https://wizardzines.com/) is also highly recommended. * If you do front-end JavaScript, then browser bookmarklets are great. Some examples are [here](https://adactio.com/journal/20965). There is a simple, but effective generator [here](https://caiorss.github.io/bookmarklet-maker/). 25. ##### You are awesome! (Remember that.) The original idea for the "Awesome Log" came from Ahmed Khalifa in [a video in 2019](https://www.youtube.com/watch?v=9CN9997K8P8). It's worth a watch. I expanded this idea to the "Achievement Log" where I record *specific* things I did at work, preferably with stats to show their impact, so that I can look back and see what difference I've made. It's also great for compiling a CV or for examples to reference in job interviews! Both of these logs are private! They're not bragging documents., 25 Lessons, forwp.dev, 01k6093mewxk3pc47tsrf9yrrg.