If you only read one thingđŽ People can read their managerâs mind (9 minute read) Worth repeating this one âPeople generally donât do what theyâre told, but what they expect to be rewarded for.â If your management doesnât work, people donât do the things you want them to do and youâre struggling with developers, this probably is the reason. https://yosefk.com/blog/people-can-read-their-managers-mind.html
Stories Iâve enjoyed this weekđ How to Lead Your Team when the House Is on Fire (13 minute read) I wouldnât call the scenario from the article âhouse on fireâ, the article describes the ânormalâ startup life. After having the âhouse on fireâ several times as CTO, this is a different kind of beast. But I digress. Or perhaps not. If the house is on fire, first thing, tell everyone. CTOs often donât tell, âthe house is on fire, the website is downâ or âweâre suspect being hacked." More often I get clients who get performance complaints from their CEO, and we discuss what to do. I ask them if they told the team that they expect performance (âhouse on fire,â or otherwise better join a large enterprise). No? Well, first thing, if you expect high performance, say so (and act accordingly). On fire? Youâd think everyone knows what to do. Once during a fire alarm, devs ask me what to do. âLeave the building?â was my response. Yes, obvious, but not to everyone. Same with performance. Declare âthe house is on fireâ if it really is (incident, running out of money, being hacked, âŚ) Back to normal times, the article goes into more details on what to do as an engineering manager in general, good points, on fire? You decide. https://peterszasz.com/how-to-lead-your-team-when-the-house-is-on-fire/ đˇ On over-engineering - finding the right balance (10 minute read) âA big debate among developers is whether to write code for todayâs problem or to build a general-purpose solution for future needs.â If you can predict the future, donât build software, play the lottery. Build for the problems you can see in the next 12 months, not in the next ten years. The article goes into more details on that trade off. Itâs crucial your engineers and managers understand that there is a tradeoff between future proofing and locking you into a direction with added complexity. https://www.16elt.com/2024/09/07/future-proof-code/ Just for Fun. No, Really. (6 minute read) âThere are hackers who just love the art of building software.â But they might not work for you. Why? Because âif one is used to consuming other software only, and rarely creating anyâ in your company, they are not creators. They build other people ideas and dreams. A long time ago, coders where creators. Then this was taken away from them. And therefor they donât work for you. If you want the best coders to work for your, with their heart in the work and not a side project, make them creators. https://justforfunnoreally.dev/ In the labyrinth of unknown unknowns (15 minute read) Everyone laughed on Rumsfeld for this. And either youâre pro, or contra, or donât care, or donât know, but his âThere are unknown unknownsâ is a good way of thinking about some things (-> Johari Window). âA Quality Assurance (QA) engineer walks into a bar. Orders a beer. Orders 0 beers.â Haha. What has this to do with unknown unknowns? âThe first real customer walks in and asks for a light. The bar bursts into flames, killing everyone.â You donât test the unknown unknowns. You donât test the unknown unknowns of the market. Or that candidate youâre interviewing. In terms of QA? Make them do exploratory testing, not executing test scripts (or write automated tests, devs need to do that, you know that, donât you?) https://www.antithesis.com/blog/unknown_unknowns/ What I Gave Up To Become An Engineering Manager (13 minute read) Some misconceptions about being an engineering manager. The gist of the article is - somehow, âI gave away things I love, but I got other things insteadâ. The first example is âBuilding Thingsâ. I do see this too often, managers giving everything away that they love and then after years they hate their job. NO! Keep the things you love and make it happen instead. Keep coding those prototypes or spikes or do R&D scouting. It also relates to the âFounder Modeâ from the last newsletter. People tell you how to be professional, but they never walked your shoes. Keep the things you love. https://emdiary.substack.com/p/what-i-gave-up-to-become-an-em Tetris in SQL (52 minute read)  Amazing what you can do in SQL. It is clear this doesnât make a lot of sense. Often itâs not so clear-cut. There is a fine balance for a senior developer to strike. How much do you bend tools Just Use Postgres for Everything - https://www.amazingcto.com/postgres-for-everything/ ) vs. when to use new tools. On the one hand you might create Tetris for SQL, on the other extreme you end up with a large tech zoo. Also, Tetris has the Guinness world record of officially running on the most systems. We have to +1 this. https://github.com/nuno-faria/tetris-sql A Startup CTO Cheatsheet (28 minute read) Not sure if I agree with all points, but it has good points and shows how much the CTO role changes during the growth of a startup. Prepare for change. From coding, to hiring, to team manager, to visionary and executive. A roller-coaster journey, next to the CEO probably the most demanding startup position. https://testrigor.com/blog/a-startup-cto-cheatsheet/ Swift is a more convenient Rust (10 minute read) Beware HTTPS is broken on that link. Swift is underrated me thinks. Playing around for some time with Swift on Linux, it seems the nicer Rust. Rust is still king for correctness and IoT with low memory and more control, but Swift is more convenient. I predict a great future (Also Ladybird switched to Swift https://blog.namangoel.com/swift-is-the-more-convenient-rust Interesting point in the article, *âRust is a low-level systems language at heart, (but it gives you the tools to go higher level. Swift starts at a high level and gives minute read).) https://xcancel.com/awesomekling/status/1822236888188498031 ). Tests and Sensibility - Surprisingly, some devs donât test (17 minute read) Comma in the URL. Looks strange, but to the article. âSurprisingly, some devs donât testâ. My experience exactly. I once needed to demand that every dev adds a comment to each ticket on what browser they tested what (Kindergarten of course, but it worked, and we could drop that rule after some months). Why donât some developers test? Some time ago I wrote âTests Are Bad For Developersâ, go read it if you havenât. The article here adds some common points, âIt worked when I tested itâ (So?), âTesting takes too longâ (Rewrite tests, use a faster language, Go is so much faster for executing tests), and âwe have a QA team, so testing is their jobâ. The last point especially is a concerning one. I once heard a story, âMy secretary always makes typos, so I need to read every letter.â You got it wrong, they made all the typos because you did read the letter and correct the typos for them. You have bugs in production not despite QA, but because of QA. Developers are responsible for quality, not QA. They need to prove that their code does what they say it does, no one else needs to do that for them. https://www.mindful-coding.com/softwarequality,/testing/2024/08/29/Tests-and-Sensibility.html Stop Scanning Random QR Codes (20 minute read) Scammers put QR codes on parking lots to gather payments, because people just scan & pay. The link could also lead to a malware site, of course, people still scan. I once had an excellent security engineer, she let USB drives lie around at the printer to see who would put random USB drive in their machine autostarting/clicking on âmalware.â Today she would probably put QR codes up in the office to see who scans random QR links inside the company that could contain malware and exploit the internal network. I have a very basic security introduction for all new hires, which includes âdonât put in any USB driveâ (if I canât control the ports, if I can I lock the ports) in their machine. Today Iâd add QR codes. https://gizmodo.com/stop-scanning-random-qr-codes-2000492837 The Art of Finishing (17 minute read) âAn unfinished project is full of intoxicating potential. It could be the next big thingâ Yihaa! This is so true for many things, startups included. As long as we keep things in limbo, they could be world changing. When we finish, they are what they are. I would not have finished my last book without the kick from my wife. Because finishing makes things real. Itâs like opening SchrĂśdingers box. Puff. Same for features, and projects in companies. You keep working and working, living the fantasy. âThe illusion of productivity plays a significant role too. As long as youâre working on something, you feel productive. Jumping from project to project gives you a constant stream of ânew project energyâ (Unsuccessful) Founders love that. If you have no vision and no strategy, you even donât know when youâre done. So you keep jumping, feeling the new project energy. âAs I prepare to step away from my desk, I canât shake a feeling of frustration [..] Despite my efforts, it feels like Iâve barely moved the needle.â My tip: The key to happiness is âOne thing a dayâ - do something every day, that moves the needle. Plan in the morning, be happy in the evening. Back to the headline, you finish something every day (I even have a sign with this slogan on my wall). Believe me, this is world changing. Join the CTO newsletter! | |
