Ed Rasher

If celebrating software maintenance is something you want to do, you should check out the Legacy Code Rocks conference MenderCon on May 16th! I’ll be giving the opening keynote: “Community Is Just as Important as Code” Registration link is in the comments.

25

2 Comments

I've been thinking a lot lately about ways of structuring IaC code, specifically - should this code be separate from application's code, or they can (should) be kept close to each other. When writing backend code, my rule of thumb about managing transactions (and other resources, like connections) is that a method or class cannot interfere with its (transaction's) state if that transaction has been started somewhere outside of that code. In simple words, only a piece of code that started a transaction should make a decision to commit or roll it back. Looks like this model can be applied to codifying infrastructure as well. If an application owns the lifecycle of an infrastructure resource, it is okay to put them in one source code repository. Short unpolished writeup on this topic: https://lnkd.in/emzDC9Nn

2

One common pain point in software development? Scope creep. Projects start with a clear vision, but as new ideas and requirements come up, it’s easy for scope to expand—and timelines to stretch. While some flexibility is essential, uncontrolled scope creep can lead to budget issues, delays, and frustration across teams. The key is managing expectations early and often. Setting clear boundaries, revisiting priorities regularly, and creating checkpoints for any changes help keep things on track without losing momentum. It’s all about balancing ambition with practicality. How do you handle scope creep in your projects? #SoftwareDevelopment #ScopeCreep #ProjectManagement #TechStrategy #TeamCollaboration #Agile

12

1 Comment

In Spring 2024, monthly churn for Copilot CRM hit 11%  At that rate, 90% of customers would be gone before the year's end. Our codebase contained 285 documented bugs. The database was fragile, inconsistent, and often experienced outages during peak hours. I had hardly slept for almost four days. It was excruciating... Not because we were losing members. Not because people were cursing at me online or threatening legal action. It was painful because the members were my friends, franchisees, and closest supporters. Everything broke. Emails got hacked, texting stopped, jobs disappeared, invoices gone.  Every time we fixed a bug, three others popped up. Regression after regression. The codebase was melting under the pressure of massive user growth. IT WAS HELL! A few months before, everything was gravy. We had tripled users for two straight months. We got to break-even without investors. Q1 2024 was on track to be profitable. We had delivered 15+ massive features in 2023. Everything was going great. So fast forward to present day.  We have reduced the reported bug count by almost 80% (we aren’t done yet!) We have had stagnant growth for most of 2024. Churn is still high at 4% monthly. Our expenses have more than tripled, and they have room to run as we continue to hire more team members. In the meantime, I bought out my co-founder to ensure I would take the financial hit required to get us back on track. We aren't out of the woods yet.   Credit is due. 1.) Most important. The users that stuck with us from the beginning. The company would have failed if everyone had left. They had every right to. I will not forget this. We have 1-2 more months to clean up the mess I created, but you have my word; I will make it up to you. 2.) The team. I am not going to mention names. They know who they are. They were unwavering in their support for me and the vision of Copilot. People have worked and continue to work around the clock. I messed up big time trying to hire engineers as a non-technical founder. I had to make difficult decisions to cut staff and rebuild from the ground up. This caused intense pain. Thank you to each person who contributed to this effort! 3.) Josh Kahle deserves a special rose. I needed to attract the best talent in the industry to turn the company around. Why would ANY great engineer step into this mess??! For some reason, Josh believed in me. He had the tech skills, experience, and connections we needed. He caught my vision for home services, software, and robotics. He cosigned on the vision of Copilot and put his reputation at stake. This gave us credibility to attract the top engineers, designers, and team members. So why am I writing all this? Where is the feel-good ending? It’s not here yet. But it's coming... If you want me to make BTS posts like this in the future, let me know in the comments. I hope it helps someone. Quitting is not an option.

16

3 Comments

The latest Qwen2.5 Coder models outperform Sonnet and 4o on some benchmarks. Try it on Wingman today!

4

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments

Dev agencies, if you don’t want to be treated as a commodity, stop acting like one. - Learn the business context for engineering needs - Stop squeezing your clients every opportunity you get - Prioritize transparency, communication, and accountability In short, position yourself as a partner that uses tech to solve business problems. You really can’t complain about being seen as a commodity if you treat everything as a transaction.

1

1 Comment

So you can't rely on code that Github Copilot spits out. Is that what's changing the job of the developer? Marcel Chabot - Development Manager and Software Architect at The TM Group, Inc. explains on Dynamics Compass that developers will be using Copilot, but it does require new activities from the developers to ensure the code is fit for purpose and safe. If you're using Copilot for development, is it saving you time or are you spending the time saved on quality checking? See the link in the comments for the full 34 minute interview. #microsoftdynamics #d365 #msdyn365 #copilot #github #development

2

1 Comment

💻 What makes code good? And why does Big O matter? 🧑‍💻 When writing code, it’s easy to focus solely on getting the job done. But great developers go beyond "just working"—they write good code that scales. So, what defines good code, and where does Big O notation fit in? 🔑 Good Code Essentials: Readable: Clean, well-organized, and easy to understand. Maintainable: Modular design for easy updates and minimal duplication. Efficient: Optimized to run fast and use resources wisely. Reliable: Thoroughly tested and handles edge cases gracefully. 🕒 Enter Big O Notation: The blueprint for understanding how your code performs as it scales. It's not just about whether your function works, but how well it works as data grows. 🔍 Consider: O(1): Constant time—quick and stable. O(n): Linear growth—manageable but scales directly with input size. O(n^2): Quadratic time—a red flag for larger datasets! Strive for clarity and efficiency, but don’t lose sight of why performance analysis matters. Big O can be the difference between a smooth user experience and a lagging one as your application grows. Remember: Good code is more than syntax; it’s a blend of clarity, maintainability, and performance awareness. #CodingBestPractices #BigO #SoftwareDevelopment #CleanCode

4

‘In this episode of “The Engineering Room” Dave Farley chats with renowned author, speaker and expert software developer Kevlin Henney.’ https://lnkd.in/gsenvBMQ ‘In their wide-ranging discussion they talk about: • Why Kevlin Henney is famous for big public software failures! • Software Engineering, mathematics and the interesting gap between formal programming and sloppy humans. • Architecture, empiricism and three ideas for design. • Coping with incomplete knowledge and making stuff that works in the real world. • Confidence, certainty and loose-coupling. • Learning from actual failure, not just simulation. • Programming is deceptively easy to start, and gets complicated really quickly: Low Code is no exception.’ Continuous Delivery Ltd Bernard McCarty #ContinuousDelivery

21

I’ve been having a few discussions with TDD aficionados.  We talked about whether they use TDD all the time. It appears that there are instances, particularly in graphical applications, where the test/evaluation is done post coding.  For example, rather than write an automated  test for an object’s depiction, they code and see whether the object appears correct. It was suggested that there may be other times when TDD might be less applicable.  For example, in a pool program, one needs to calculate the result of two balls colliding.  The inputs are the balls’ positions and velocities, and the outputs are the balls’ new velocities. (One could add angular velocity to make it a little harder.) So, I offer this as an interesting problem. Can this function be developed by TDD?  If so, what are the steps? Daniel Moka Al Shalloway Rob Myers Justin Beall Tim Ottinger John Crickett

6

38 Comments

Copilot and development: What activities are easy to automate? Hear what Marcel Chabot - Development Manager at The TM Group, Inc. uses Github Copilot for: - Writing up to 50 lines of code - Clean up long and complex code - Write documentation - Explain what the code does How have you been using Github Copilot to make your job easier? Want to see the full 34min interview? Click the link in the comment section. Dynamics Compass #github #copilot #microsoftcopilot #msdynamics #microsoftdynamics #msdyn365 #d365

2

1 Comment

Another thing I do is track my time, religiously. Every single bit of "work" time I spend is tracked by client (which is sometimes my own company), project, and task. This makes it easy for me to see what I was doing, when, who it was for, and how long it actually took. I can also generate reports to see how much time I spent on certain types of tasks, including mundane things like "Processing" (which includes email, Slack, etc.)

5

Why Code Reviews Aren’t Just a Checkbox, and How Code Generation Tools Can Help In fast-paced development environments, it’s easy to treat code reviews as just another task to check off. But in my experience, code reviews are essential for maintaining code quality, enforcing standards, and fostering team collaboration. They’re not just about catching bugs. Reviews improve code readability, consistency, and knowledge sharing. Rushing or skipping them often leads to technical debt and issues down the road. As teams scale and deadlines tighten, AI-powered code generation tools can help by automating repetitive tasks like code duplication checks or comment generation. But here’s the thing—AI tools don’t replace code reviews. AI can’t make judgment calls about: - Whether code aligns with business goals - How well it fits into the architecture - Whether there’s a better solution AI should assist, not replace, human judgment. Let AI handle the grunt work, but real code quality comes from thoughtful, human-driven reviews. Code reviews are opportunities for growth and quality—don’t treat them as a checkbox.

36

2 Comments

I thought this was an interesting reddit thread. Something I’ve been thinking about too, Salesforce says it won’t hire any software engineers this year due to AI. I mean if Salesforce no longer needs engineers because AI is that good, them why would the companies that use Salesforce need Salesforce? Can’t AI just build a custom, fit to purpose Salesforce? These decisions by tech companies seem short sighted or at the least simplistic… https://lnkd.in/ec-b7HDn

3

1 Comment