Code is run more than read • Hacker News Board

Re: Code is run more than read

#321

Post by Raed667 » Sun, Dec 03, 2023, 10:25 AM UTC

SpaceNoodled wrote: post #262

Gabrys1 wrote: post #254

Earlier quoted context omitted.

I used to work at a company that sold SaaS to big corporations. We needed to win contracts, so we needed to tick their checkboxes, but we also cared for the user experience (good UX was almost never a strict requirement from our customer). Our competitors' software was very painful to use, so we wanted to differentiate in this regard. This made our own lives easier as the training was easier, the users we interacted…

I wish more companies realized your last point.

I tried to be that guy that recommends better software whenever I changed companies. Unfortunately, being new also means you're not always taken as seriously and you are stuck with whatever crap that is used instead of the better experience you used to have.

Re: Code is run more than read

#322

Post by wruza » Sun, Dec 03, 2023, 11:30 AM UTC

YoshiRulz wrote: post #224

wruza wrote: post #146

Earlier quoted context omitted.

To ditch the biz we have to make dev and ops accessible to ourselves. Nobody does that. Making a proper login form still requires a team and a week. The biz sits there rubbing its hands, watching us making the means of production more and more complex and expensive to use, so that it has a complete monopoly on creating software. Devs are so used to relatively big paychecks from the biz that unconsciously tend to igno…

It's interesting to hear you say that reducing complexity and building to last(?) is the solution. Do you know of any case studies (not even peer-reviewed necessarily, just examples) showing a "recovery" in terms of user freedom after making such changes? My view has always been that complexity should be reduced, but because it makes maintenance easier—reducing cost if you're paying maintainers—and can prevent bugs/v…

The kind of complexity I mentioned never gets reduced, or so to say the reduction happens in volumes, not in levels. E.g. an app that uses fetch() to access backend that uses SQL/DDL to init and access database. It never gets reduced into a thing that models data graphically and then uses out of box objects in frontend like `await main_obj.get_linked_obj()`. But it may be simplified by removing all the abstractions which ought to poorly simulate this but failed. A maintainer skill is still required to be high, only their mental capacity is taken care of.

Keywords in the last point are from all over the stack. They should be erased from code in favor of much simpler concepts. How you name the users table, which routes access it, should that be fetched or cached, how to structure code to display it — all that is not a businesses business. It should look like e.g. “root.current_user = await User.login(username, password)”. Everything else is low-level.

Re: Code is run more than read

#323

Post by yndoendo » Sun, Dec 03, 2023, 5:50 PM UTC

dkarl wrote: post #280

t43562 wrote: post #147

Some users are not using a system because they like it but because their company bought it. In those situations biz > user by definition and the developers end up having to cater to the needs of the middle managment of their customers rather than the needs of the actual users. The price of not doing this is failing to win the contract. Users then get locked in to whatever crap you have time to provide for them while…

I worked at a company in a market with similar purchasing dynamics, but we focused exclusively on the users. We committed to a "product-led growth strategy," which meant no salespeople. Product focused entirely on the user experience. The problem was, we weren't selling to users. We were selling to people in the users' organizations who purchased software. These people did not have the same job as the users, and they…

Those that write the checks are also a user, just with different expectations than the daily user. Management is also a user that differs between the check writers and actually end users.

Re: Code is run more than read

#324

Post by kindkid » Sun, Dec 03, 2023, 9:43 PM UTC

4death4 wrote: post #247

bearjaws wrote: post #245

Earlier quoted context omitted.

In enterprise software, you cater exclusively to management, they will turn a blind eye to 99% of issues as long as the team is able to get the work done. Take one look at EMRs and realize that its sold / marketed to .01% of the hospital, despite 80% of the health system using it.

> In enterprise software, you cater exclusively to management, they will turn a blind eye to 99% of issues as long as the team is able to get the work done. Again, you can exclusively cater to management, but you don’t have to. Look at Datadog. It’s a great product, but still ultimately purchased by management.

Also, look at their competition. New Relic's product is so painful and broken that despite successfully winning deals with many large companies, they still manage to lose business to Datadog as their end users work extremely hard to convince management to not renew, and switch to Datadog, for the good of the company. Ask any insider.

Re: Code is run more than read

#325

Post by krzychukula » Sun, Dec 03, 2023, 10:40 PM UTC

solatic wrote: post #12

> And while we can’t just go back to ignoring the economic realities of our discipline, perhaps we should take a stronger ethical stand not to harm users. Acknowledging that the user may not always come before the business, but that the business shouldn’t unconditionally come first, either. This is why software engineering needs licensure. Not to check if people understand design patterns, or whether people know the…

IMHO. The article makes a wrong call to action. It calls for dev ethics when the problem is biz ethics. Instead of licensure wouldn’t it make more sense to have more rules and oversight for the companies?