If you only read one thingManaging difficult software engineers (22 minute read) Not that I agree with everything of the article, but there are many good points in it, although most of them are too optimistic for my experience. But Iām an old one. āManaging a Procrastinator requires a balance of firmness and support. Set clear deadlines and regularly check in on their progress.ā Or The Lone Wolf, The Negative Nancy, The Over-Promiser, The Know-It-All, The Perfectionist, The Unreliable One, The Conflict Instigator and more. Can you spot one of your developers? This reminds me of Mr. Men ( https://en.wikipedia.org/wiki/Mr._Men ) - a book I always have on my desk. https://vadimkravcenko.com/shorts/managing-bad-engineers/ Tweet of the weekāChatGPT can create a complete startup. With just one prompt, you can: ā Create a website ā Generate a logo ā Perform a market analysis I show you how to do this using 3 pluginsā Paul Couvert https://twitter.com/itsPaulAi/status/1694716540694982722 Graph of the weekFront-end frameworks popularity (React, Vue, Angular and Svelte) from https://gist.github.com/tkrotoff/b1caa4c3a185629299ec234d2314e190
AIMaccarone: AI-managed code blocks in Python (8 minute read) You write the skeleton and āAI code goes hereā and the AI fills in the code. Done. Silver bullet. It is amazing how fast we change. https://github.com/bsilverthorn/maccarone
Introducing Code Llama, an AI Tool for Coding (9 minute read) āToday, weāre releasing Code Llama, a large language model (LLM) that can use text prompts to generate and discuss code.ā from Facebook. Copilot at home. Playing around with it, love it, just ordered an Nvidia 4090 to make it faster. Yes, it might be that we go the AWS route, and you train an AI e.G. at Jetbrains or GitHub. Or you might do it on your own. We donāt know yet how AI works. Better be prepared. If none of your developers are playing around with Code Llama, youāre doing it wrong. https://about.fb.com/news/2023/08/code-llama-ai-for-coding/ Stories Iāve enjoyed this weekYes, you can measure software developer productivity (16 minute read) This article created a wave all around software development. For decades, we could not measure productivity, now we can! There we are again. For every CTO out there: Change the framing to impact instead of throughput. The article reiterates that you should apply DORA and SPACE metrics (not discussion there, itās the closest thing we have to an industry standard). There are good points in the article, like managing developer satisfaction, retention and interruptions. Go read it. Then change the framing to impact. Thank me later. Top 7 Things That Kill Developer Productivity (15 minute read) There was this Harvard Business Review article some years ago about motivation. The takeaway: āDonāt motivate people, stop demotivating them.ā The same goes here. Often I get asked about developer productivity. First thing, donāt kill it! I agree with most of the points in the article (see for yourself). https://dev.to/surajondev/top-7-things-that-kill-developer-productivity-ef9 How to sabotage your salary negotiation efforts before you even start (30 minute read) āAlways the dollars. Always the $?@ dollars.ā (Nicky Santoro, Casino). Must read if you are out for a new job and get into negotiating your salary. āThese are the two things you must avoid [:] 1. Revealing information too early in game 2. Negotiating before youāre readyā. I want to add: The first number that is spoken is the anchor, if they say 80k, itās hard for you to get 120k, because 80k is the anchor. Second: Donāt ever tell your current salary, the most youāll get is 10% more (Exception: Your current salary is hilariously high). Third if pressed, ask for their range for that position. If pressed harder, answer with a range: Between 120k and 100k. Last tip: Add 5k or 10k on top of your comfort zone. https://interviewing.io/blog/sabotage-salary-negotiation-before-even-start How architecture diagrams enable better conversations (12 minute read) Iām a strong believer in writing down org charts, roadmaps, architecture as a base of discussion. With everyone having different, fuzzy perceptions in their head, it is difficult to get to an agreement āFocuses communication [..] Universal understanding [..] Facilitates planningā https://www.unravelled.dev/how-architecture-diagrams-enable-better-conversations/ Railway Oriented Programming (8 minute read) Railway oriented programming (ROP) means there are two tracks in your code. The good track, and the error track. And there are railway switches that take you from the good track to the bad, but never back. The implementation of this is most often Monads, like Either and Option. While with Go I no longer do this, ROP is one of those ideas that changed my developer mind. If your developers donāt know this yet, make a talk and tell them. https://fsharpforfunandprofit.com/rop/ How to avoid KPI psychosis in your organization? (7 minute read) āJust to give a glimpse: we take information that is easiest to gather (availability bias), often that is heavily affected by the latest info we got (recency bias) and when we make conclusions, we tend to overgeneralize (halo/horn effect) with more confidence than it was justified by our lintels (overconfidence bias). On top, we are typically stubborn and seldom change our opinions and worldview (anchoring bias, confirmation bias).ā I also am amused (and desperate!) when people are confusing KPIs, goals, OKRs and metrics. All these things are different, and solve different problems, but often are confused into one number. https://blog.promaton.com/how-to-avoid-kpi-psychosis-in-your-organization-5ffc83967f2b Squeeze the hell out of the system you have (9 minute read) āWe should always put off significant complexity increases as long as possible. When complexity leaps are on the table, thereās usually also an opportunity to squeeze some extra juice out of the system you have.ā https://blog.danslimmon.com/2023/08/11/squeeze-the-hell-out-of-the-system-you-have/#like-2777 Donāt Build A General Purpose API To Power Your Own Front End (7 minute read) āI suggest you stop treating your frontend as some generic API client, and start treating it as a half of your app.ā Just recently I have seen this, developers building a complete API for a limited use case. I thought about all the lost time, the opportunity cost, the future maintenance costs and the hybris of developers who think they can anticipate the future. Not sure if I agree with the article solution, but itās worth a read. https://max.engineer/server-informed-ui Fuzz Testing Is the Best Thing To Happen to Our Application Tests (12 minute read) āWe introduced the first fuzz test into the QuestDB project in an attempt to make the database more robust, and since then we have added many more of them. Itās hard to quantify the bugs found by fuzzing, but [..] itās a very rare case nowadays to see a critical issue reported by the community.ā Fuzz testing or fuzzing is running a test with random values, sometimes for a long time. If something breaks, the test stops working, or the code crashes. The values are recorded; you can fix the problem. Itās similar to property-based testing, but while property-based testing tries to find the minimum values that show the bug, fuzzing is brute forcing millions of values. To me, fuzzing is a secret that can give you the edge in QA**. https://questdb.io/blog/fuzz-testing-questdb/ āThe Onionā founder explains his strategy for sparking creativity (18 minute read) Where does creativity come from? āThe Norse believed Odin could unbind peopleās minds with the power of the runeā Ah! But creativity saves your startup, not throughput. https://bigthink.com/the-learning-curve/the-onion-founder-strategies-sparking-creativity/ Join the CTO newsletter! | |
