← Back to context

Comment by bnug

3 days ago

That could be the case, but I work in a mechanical engineering group as the only person on the team who can write code or automate things with it. We're in a large corporation with a sizeable IT support group that builds a decent chunk of the software in-house, and our team views much of it as terrible. So, I've rewritten applications or supplemented the "terrible" but irreplaceable software with tools to make our jobs much easier. I don't think that I'm better than our in-house IT folks at software development but that my perspective as an actual end-user gives me a much better idea of how to meet our own needs. I'm also highly motivated to make it effective, since I'll be using it. So, the title initially resonated with me and didn't see this comment coming. That said, I'm sure your point is valid in many cases as I'm not familiar with formal software development / project management.

100% agree with this take. I work in observability space. We use our own product to monitor our services, and being a daily user of the product helps us make it better. Our customers also agree. We get opportunity to talk to our customers doing product demos at conferences, etc, and all the feedback I have gotten is that they love the product! But wish it was cheaper.

There's 2 ways you can get to working software

1. Professional software engineers that can listen to learn about the problem space and are willing to come to understand that. This takes humility.

2. The people experiencing the problem. They might not write perfect code and it might not be maintainable long term. But their understanding of the problem and pain points is so good that they can solve just that and not write 90% of the code the professionals wrote...

I've seen this over and over again and can only tip my hat to the people that fixed their own problem. Just like for a dev, that means going into an unfamiliar domain and teaching yourself