Andy Grunwald’s Post

Ich kann mir kaum vorstellen, dass so viele Leute uns bisher zugehört haben 🫣

If you worked for trivago and know Rolf Schroemgens you know what to expect … 🤯

Mal ein Reality-Check zum Softwareentwicklung AI-Marketing-Hype 🔎 Überall lese ich nur AI hier, GitHub-Co-Pilot da, Devin als AI software engineer dort drüben und alles sind immer Success-Stories. Das macht mich etwas stutzig mit der Frage "Ist das Gras wirklich so grün da drüben?". Deswegen hab ich mich etwas mit den AI-Basics beschäftigt und bin recht schnell auf verschiedene Fragen gestoßen, wie zB: ❓ Warum ist gerade Source Code so gut für LLMs geeignet? Ist es nicht so, dass Software-Entwicklung ein unglaublich kreativer Beruf ist? Und sind Halluzinationen nicht ein wirkliches Problem? 💡 Es wiederholen sich immer nur Patterns über Patterns über Patterns ❓ Wenn der Kontext und Prompt, also der Input den ich dem Large Language Model (LLM) gebe, auf eine gewisse Anzahl an Tokens begrenzt ist, wie funktioniert dann der richtige Code-Vorschlag ordnungsgemäß bei etwas größeren Software-Projekten? 💡 Die Antwort: Retrieval Augmented Generation ❓ Ist ein 55% Productivity-Boost, wie GitHub ihn durch die Anwendung von GitHub-Co-Pilot verspricht, denn wirklich realistisch? 💡 Die Antwort: Ja und Nein. Die Zahl ist etwas aus dem Kontext gerissen und ggf. nur auf die eigentliche Software-Entwicklungszeit anzurechnen. Ein Software-Entwickler entwickelt ja auch nicht 100% der Zeit neuen Code, sondern hat Meetings, updated Tickets, schreibt ein Design Document, liest Dokumentation, trinkt Kaffee ☕, ... Aber nun stellt ihr euch natürlich auch eine Frage: ❓Andy, woher weißt du das alles? 💡 Im Engineering Kiosk-Podcast hatte ich die tolle Möglichkeit mit Birgitta Boeckeler, zur Zeit Global Lead for AI-assisted Software Delivery bei ThoughtWorks, zu sprechen und mir das für "Late Adopter" erklären zu lassen. Wenn ICH also DU wäre, würde ich mir den Podcast unter https://lnkd.in/edjtMrMe auch mal anhören 🎧 Danke nochmal an Birgitta Boeckeler für deine Zeit (und Geduld). Durch den Podcast hast du mich als (ggf. ursprünglichen Skeptiker) überzeugt :) PS: Wie im Podcast versprochen, habe ich nun auch einen GitHub Co-Pilot installiert und bin doch recht beeindruckt. Wenn man weiß, was man programmieren möchte und dies auch ordentlich beschreibt, kommt da schon guter Code bei rum. Danke Birgitta Boeckeler und Wolfgang Gassler fürs pushen :)

It is beautiful to see that the evergreen strategy we chose for the Engineering Kiosk Podcast 🎙️is working out. The graph 📊 below shows that ~50% of our daily listeners tune into podcast episodes that are > 30 days old. This makes me especially happy, because we don’t create throw away content. We create content that has value for a long time. You may say „sustainable content“ 🥹 If you don’t know or new to the Engineering Kiosk podcast, scroll through our evergreen content at https://lnkd.in/d3d6F_Wq Cu in the next episode 👋

Sometimes, you read a blog post and think "What a great piece of writing". I had this a couple of times already. Even more, I came back to certain articles and read them again. I call it an "All time high" article. Here is a list of my all-time-high articles ⬇️ „Choose Boring Technology” by Dan McKinley Hackernews Driven Development is great. The new. The shiny. But using boring technology is 100% underrated. To know the failure patterns, you just get shit done. Nowadays, I appreciate boring technology. https://lnkd.in/eZMT7MpY -- Maker’s Schedule, Manager’s Schedule” by Paul Graham This masterpiece describes the most prominent conflict between knowledge workers needing long windows of focus time and managers grinding through back-to-back meetings with a 5-minute break in between. https://lnkd.in/eGf2dyNz -- „How to Create Luck” by swyx Actual luck might not be real luck but can be influenced by doing/telling. You expand your luck surface area on your own. This piece changed how I think about my efforts and the good things that happen to me and others. https://lnkd.in/eGpQwiv6 -- „Does your Company have a Think-first Culture?” by Itzy Sabo Itzy’s article had a tremendous impact on how I think about “writing first”. If you are not convinced about written words in the first place, read this and get the *aha” moment. https://lnkd.in/eSTyBc_b -- „The Engineer/Manager Pendulum” by Charity Majors She is loud about one thing I believe in: Moving from Engineering Management back to an individual contributor role is not a shame, but it can benefit your growth. Doing this is called "the pendulum". https://lnkd.in/evJAYzcy -- „Why Software Is Eating the World” by Marc Andreessen Published in 2011, it is fascinating how accurate this article was and is still today (in 2024). Software is everywhere. Maybe software is even in places where we humans would be better off without it. https://lnkd.in/esNW5PGR -- „Clever, Stop Being So” by 🐈 Kitty Giraudel How complex can a supposedly simple topic actually be? Kitty provides a superb storyline for why dealing with names, especially in worldwide used products, with diversity and inclusion in mind, can be hard. https://lnkd.in/ev_zRY72 -- „Startups, Write Changelogs” by Karri Saarinen I love this due to its simplicity and positive effect on the team. It doesn’t need to be a long blog post. A few lines are enough - just getting things done. Reminds me of brag documents as well. https://lnkd.in/e2g3pY6m I hope you enjoyed reading through those masterpieces and got something out of it. I summarized all this in a blog post, which I update continuously. Check out the list here: https://lnkd.in/eRHu8ET5

One of the key questions I like to ask "How does success for [you/this project] look like?". Surprisingly, this is a pretty hard question for many people. Even harder this question gets if you ask it in the context of your life. A good thought experiment and good use of time to think about.

Run your Continuous Integration every day ... ... even if there are no changes to your code repository. But why should you do it? Today's software is getting more complex. Often, this is equal to more dependencies. Dependencies like external libraries or external services. Those external dependencies can and will break without you noticing it. Common examples of broken dependencies are: • A library gets deleted from Github • The container or package registry (npm, Packagist, Pypi, …) is down or is changing APIs/URLs (and reminds you to set up your own mirror) • You generate data based on an API Call during the CI process, and the API is down • Your build process sends telemetry data to some service (usage data, build times, …), and the network is failing What is the solution? Run your Continuous Integration every day, even if there are no changes to your code repository. This will detect dependency failures early and keep the software buildable. How do you run your CI process daily? Schedule your CI system to run the CI process daily at a particular time (e.g., 3 am). Every system is capable of this: • GitHub Actions • Jenkins • CircleCI • Bamboo • TeamCity • and ... Cron ;) Any downsides to this approach? Depending on how your CI is built, this can create additional costs. Imagine your cloud app that starts 100 nodes in each hyperscale cloud each CI run. It depends on your environment and context. You are the best person to evaluate this. If you want to know more, I wrote a small blog post about it: ➡️ https://lnkd.in/e9_Pwsfn

Sometimes, surprising things happen on the internet. Oren Ellenbogen decided to share my article "Cancel your meetings if you can live with the outcome" in his Software Lead Weekly (in issue 582). I feel honored. This is one of the rare newsletters I open and read every week. If you are into Engineering Leadership (or want to move in this direction), check out the Software Lead Weekly Newsletter. Read the Issue 582 (incl. my featured article) here: https://lnkd.in/ePEFBiwk If you are only interested in canceling meetings, go this way ➡️ https://lnkd.in/eA3Hq89W

After 11 years of organizing the Web Engineering Düsseldorf Meetup (2012 - 2023), I handed over the meetup ownership to Dario Tilgner to continue running the meetup with a new perspective, new spirit, and refreshing approach. In the last 11 years (2012 - 2023), we ... • organized over 90 meetups (including a three-year pandemic break) • collaborated with 16 different local companies • provided over 120 speakers a stage for public speaking • and build one of the most prominent and most active meetup groups in Germany with > 4.500 group members The goal has always been to ... • empower everyone to learn about Software Engineering • share experience and knowledge about industry trends • create a place for networking, experimentation, and public speaking • offer space to show, tell, and be proud of their work From our perspective, we were successful in our goals, and the numbers tell for themselves. Now, it is time to focus on something different. At the end of 2023, my peer Dominik Siebel and I handed over the Web Engineering Düsseldorf Meetup ownership to Dario Tilgner. We are glad to be able to find such a passionate person like Dario who shares the original goals with us. Onto the next 11 years of a monthly local tech meetup in Düsseldorf 💪 A massive shoutout to the local companies who believed in us and supported us over the years: trivago, sipgate, InVision Group, Vodafone, The Stepstone Group, TWT Group , METRONOM GmbH, METRO Markets GmbH, Valtech Mobility GmbH, Peakwork, SMS digital GmbH, TYPO3 GmbH, Babiel GmbH, CGI, CHECK24 Vergleichsportal und Breuninger. PS: I reflected a bit on the lessons learned from running a local tech meetup for 11 years - You can read it here - https://lnkd.in/ePRfpbT3

Cancel your meetings if you can live with the outcome. This is one crucial work rule I was introduced to at a previous job. Many people attend meetings only "to know what is going on" or "to be informed about the outcome". That is what meeting notes are for but in the end, every one of us is complaining about having too many meetings or that those interrupt our focus time. Software Engineers and other knowledge workers need long timeframes of uninterrupted time to get meaningful work done. Why not start to be comfortable with canceling the meetings and reading the outcome later? When do you have enough time and at your own speed? That is where the rule > You can cancel every meeting as long as you live with the outcome. comes handy Do you give it a try? PS: I wrote a blog post about why it is useful - Check it out: https://lnkd.in/eA3Hq89W