If you only read one thingHow do we learn? Iām a great follower of an apprentice model. Seniors should manage interns to make them better, then juniors to pull them up to senior level. Two-people teams are great. What is ShuHaRi? A learning technique āShu: In this beginning stage students follow the teachings of one master precisely. Ha: At this point students begin to branch out. Ri: Now the students arenāt learning from other people, but from their own practiceā Many CTOs have no plan for learning in their department. This is a model to apply in your people development plan. https://www.martinfowler.com/bliki/ShuHaRi.html Tweet of the weekWe all draw icebergs the wrong way. Including me. But the look so much nicer when you draw the wrong. You can play with icebergs here https://joshdata.me/iceberger.html. What else do you draw wrong?
https://twitter.com/GlacialMeg/status/1362557149147058178 Video of the weekLove everything from Elle, but this one in particular. How do they come up with these ideas?
Source: https://www.youtube.com/shorts/j7SByXWWVzU
Stories Iāve enjoyed this weekGarbage Collect Your Technical Debt (28 minute read) A deep article on how to avoid or reduce technical debt. My main points on technical debt are (mostly) not covered in the article. Constant refactorings on every feature. Every developer needs to read the book though. Second, major refactorings are needed because business and tech are not aligned. Tech is building something for a future that doesnāt arrive, because tech is not aligned with business. Talk about the future, talk to business what parts are fast, and what parts are slow. What parts are easy to change (configurable) and what parts are hard to change. Architecture is a business decision. https://ieeexplore.ieee.org/document/9520328 Why Shift Testing Left Part 2: QA Does More After Devs Run Tests (21 minute read) Iām all for giving QA (Quality Assistence) more importance in software development. And shifting left really means: QA talks to product during discovery. QA are those people who know the product best (PMs often only know a small part, the one which they are responsible for, QA knows everything), and after customer support, know customers best. Shift left, but donāt stop with development (also, shift left: Developers write all the tests). https://thenewstack.io/why-shift-testing-left-part-2-qa-does-more-after-devs-run-tests/ Why Now Is The Best Time To Be A Solopreneur (23 minute read) It gets easier and easier to become a solopreneur. Donāt get disruppted by one. As CTO ask yourself: What would I do as a solopreneur? Do I need all these developers? Can I automate more? What am I doing wrong just because I have so many developers? https://www.forbes.com/sites/aytekintank/2024/06/04/why-now-is-the-best-time-to-be-a-solopreneur/ ISO IEC 6060 : Alarm Sounds (6 minute read) Listen to these sounds! I didnāt now that medical alarm sounds are standardized. This got me wondering: How could I use sound in my SaaS app? How can you use sound? Does your app monitoring have sounds? Why not? (I only think Linkedin has sounds on my Desktop, I donāt think I hear anything else, a wasted opportunity). I thought it was inbox zero? Know it is inbox ten? The inbox ten point of the article is great, but I do disagree with many other points, violently with āNo single system for managing communication is inherently better than another, it is just a matter of what works for you.ā The medium matters, an email is different from Slack which is different from a video call. Emails are perceived different from Slack group chats or DMs. As an engineering manager, you donāt chose the communication that āworks for youā, but the one that works best for the message (donāt fire by email! Donāt update the culture by Slack). https://boz.com/articles/inbox-ten Encryption At Rest: Whose Threat Model Is It Anyway? (25 minute read) When I talk to clients about security, encryption at rest often pops up. āOne of the lessons I learned [..] is that the threat model for Encryption At Rest is often undefined.ā This article brings two good things: 1.) An explanation about why encryption at rest is a good thing. 2.) Thinking in threat models. When you develop your application, think in thread models. Do you want to encrypt data in your database? Think in attack vectors. Donāt cargo cult security. From the article āNow Bobās full name is set to Aliceās email address.ā Curious now? I do think this is great, because we need to stop that one part of the code is trusting all the other code in the code base. Your code needs to be paranoid! https://scottarc.blog/2024/06/02/encryption-at-rest-whose-threat-model-is-it-anyway/ Automatic Check-ins Reminder (3 minute read) āIād like to refresh everyone on the importance of our weekly and daily check-ins.ā 1.) Good. 2.) BUT if developers donāt come to your meetings, then there is nothing in those meetings for them. I have this discussion with clients again and again. Developers donāt want to come to the meetings I schedule (or to company all hands!) Most often the reason is, you are the only one benefitting from those meetings, so you want them and you find them necessary. If someone doesnāt get something out of a meeting, why should they attend? Every meeting needs to be structured in a way that there is something in it for everyone. Or else they wonāt come. A mail āreminderā to everyone will not work. https://public.3.basecamp.com/p/JJdipuniYbuwyy8MrVjwtzkn My Last Five Years of Work (31 minute read) āEssentially anything that a remote worker can do, AI will do better.ā Not sure about the five years, more like ten to twenty, but yes, everything will be replaced. For CTOs, the first thing that will go are data analysts (and QA that does testing (which QA should not do!)). https://www.palladiummag.com/2024/05/17/my-last-five-years-of-work/ Donāt DRY Your Code Prematurely (50 minute read) DRY (donāt repeat yourself) is the most misunderstood coding concept. For some reason it has become the battle cry of millions of coders. In reality this leads to code that is hard to adapt, instead of code that is easy to adapt. DRY results in code that anticipates a future of change that might not come, and makes real changes needed in the future difficult. Now Google says so ;-) For things that need to change together: DRY. For things that donāt need to change together: Repeat yourself! Having the same code in two places is often a good thing. The code syntactically looks the same, but context and semantics are different. https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html Join the CTO newsletter! | |
