If you only read one thingPoisoning the day (21 minute read) What a mind-popping article I stumbled across. Iāve been thinking about developer productivity for a long time now. This is obvious, but the metaphor of poisoning the day is new. āThis, to me, is what 90% of productivity advice on the internet is really about: how to get through as much of your day as possible before something takes you out.ā What is it that takes you out? The incident? The politics? The meetings? Can you avoid that? I start working at ~5:30am, I get nice things done before breakfast. Nothing killing me there. āSame with digital minimalism. No phone, no early morning notifications [ā¦] So how do you actually manage this? Embarrassingly simply. Best option: Get as much done as early as possible.ā Excellent advice. For developers? Move all meetings to late afternoon. Coding until lunch. Get things done before something poisons your day. https://ashore.io/journal/crossover-creativity/poisoning-the-day
Stories Iāve enjoyed this weekThe Pre-Contagion Window (8 minute read) Excellent article on what happens when someone new joins a company. āDepending on their level of experience and outspokenness, they will note or perhaps complain about a lot of things.ā I have talked about this a lot with my clients, but havenāt read about it. Happy to see others have recognized this too. āMake an effort to be extra patient with these complaints.ā I would even add: Ask them about everything that looks funny or weird to them. In the first two months they can recognize these things, then they are part of the culture, good or bad. For CTOs and engineering managers, joining a new company: Attack problems in the first two months. Because in the first two months you are part of the solution, and you have a huge lever to change things. After two months you are seen as part of the problem. https://kristiandupont.medium.com/the-pre-contagion-window-4ca5ec7bc968 Your PR Process Is Killing Morale and Productivity (15 minute read) Is your PR process a pain? Do PRs queue up? They did in some companies Iāve joined as CTO. Why does every commit need to have a PR review process? It doesnāt. And especially: āIāve recently come across a discussion where a new developer joined a team and faced over 300 PR comments on their first contribution. Most of it was stylistic nitpicking.ā Stylist nitpicking is also what I see most. The article identifies some reasons for this, like not having linters. And some solutions. I might add, for code review make your expectations as a CTO clear, otherwise everyone is reviewing what they want. e.g. say āI expect that code reviews catch critical bugs and security issuesā. Also read the āChecklist Manifestoā by Atul Gawande. And not all code needs to be reviewed. Really. https://blackentropy.com/your-pr-process-is-killing-morale-and-productivity/ Can You Measure a Technology Teamās Efficiency? (15 minute read) No. Or you read the article. Some good points in it, " https://www.scarletink.com/p/can-you-measure-technology-teams-efficiency Details from interim court of inquiry report into HMNZS Manawanui incident released (7 minute read) A ship sank because the crew thought the rudder was not working when in reality the autopilot was on. And because the captain for sure didnāt want to sink the ship, one has to ask: Why was the UI in a way that no one found out? What about a large red light on the bridge when the autopilot is on? Does your UI have the same problems? One of your admin tools? A dev once took down our database because he thought the SSH shell was on the test system. Same thing. At least we didnāt sink the ship. The Futility of Cross-System Integration Testing (25 minute read) Very long article on integration testing. I donāt agree with parts of it, but it covers some interesting points āBasically, if you donāt have āthe world looks like Xā directly in your test methods, your tests are terrible.ā My take on integration testing? For my latest project I switched from web-driven integration tests to tests that directly use the backend controllers and then check HTML etc. (Also donāt mock the database, IO is fast enough today). The downside, it doesnāt test JavaScript. The upside: No flakiness. Playwright was terrible for flakiness. I do think many people start integration testing, then it gets flaky, then they stop maintaining the tests and stop writing new ones. What to do? A lot of flakiness is from the browser, and how it fires events in random sequences and latency. Drop the browser (a trade off!) and directly test your controllers with your normal testing framework. If you have a JS frontend, tough. If you have a JS frontend and your business case doesnāt need one, ouch. The article is a very long read, it might help you either way, so Iāve put it here. https://www.draconianoverlord.com/2017/08/23/the-futility-of-cross-system-integration-testing.html/ A Washing Machine for Human Beings, from 1970 (8 minute read) Some innovation doesnāt take off. One thing that astonished me on Tokyo was seeing a Toshiba washing machine in a museum - when I knew Toshiba only from laptops. https://www.core77.com/posts/134471/A-Washing-Machine-for-Human-Beings-from-1970 A Beginnerās Guide to Switches (38 minute read) Too much detail about keyboard switches? But then again, developers are typing and typing and typing. So a keyboard is an important tool for developers, and it doesnāt hurt knowing more about switches. I liked it. But I also own this keyboard switch sampler:
PLUS: Best keyboard ever is my CIDOO V75 Pro (and I have used many keyboards, including several Thinkpad and steel IBMs). https://www.theremingoat.com/blog/beginners-guide SemVer works fine for libraries, but not for applications. Especially with continuous deployments. I show the git commit hash as a version number on my app pages to see what is deployed (Also sometimes helpful for customer bug reports). This one is a little more sophisticated with a sortable date and the deployment pipeline included. Iād use it if I was running a development team. Iām A Developer Not A Compiler (12 minute read) In 2024 interviewers still ask āWhat package is List in?ā and then wonder why they end up with developers who donāt take ownership, donāt feel responsible, donāt take initiative and arenāt motivated. Yes, skills are a k.o. criterion, let them code, let them read code and explain it, check soft skills but then check if they take ownership, feel proud, and are motivated. A client this year asked me āStephan, a newly hired developer isnāt motivated. What can I do?ā Hire motivated people, duh. But then someone asks āWhat keyword do you use to inherit with?ā instead. (Book an interview workshop for your developers and managers with me, also works fine) https://news.radio-t.com/post/i-m-a-developer-not-a-compiler How Fast Does Java Compile? (13 minute read) High compile times are key to developer frustration (interpreted, āruntimeā compilation has its own challenges). So one wonders why we do not have a rigorous testing approach and comparison for compile times - like gamers test hardware with FPS in Cyberpunk 2077. I appreciate everyone measuring and optimizing compile times. This one is interesting. Not because of the speed of Java compilation, but because of the huge differences from running the compiler single-threaded by hand (115,600loc/s), with a fast build tool (26,800loc/s) and a slow one (6,100loc/s). Also, devs choose computers on how hip they are, instead of how fast they compile. I wonder if van Gogh also bought the hip brushes. https://mill-build.org/mill/comparisons/java-compile.html Join the CTO newsletter! | |
