Comment by steveBK123 | Hacker News Reader

Comment by steveBK123 | Hacker News Reader

Parent Full thread

I work for a guy now who basically picked up some coding in his 30s because he found the previous business team he was on was more successful because of it. His code isn't great, but he can express what he wants in giant SQL blobs and then we can build scalable solutions against basically his mockups. He can also unblock himself for a while with his own code while we build the real production flavor, etc.

It's great because he is basically expressing his requirements in something that works.

I think just like the coders should learn the business they work in, if the business learns some code.. everyone can be a lot happier.

In the low code context I think if you can all agree to treat whatever is generated there as throwaway prototypes, then it can be a value add. Ie - instead of writing a 20 page document, I'm going to show you something that sort of works here.

The pain comes from people thinking its going to replace developers, getting stuck, and then forcing the developers into the low-code tool too.

CTE was a game changer for regular business people I work with being able to express what they want in SQL.

SQL is still dreadful, apart from all the alternatives.

In these scenarios these low code tools feel like the evolution of excel. How many times did people who couldn't write full on apps throw something together with some excel formulas to do a version of what they needed?

At a previous company, where we developed and built medical devices that were not just a toothbrush, we couldn't install or build any software that did anything that made almost any decisions about the design or production of the devices. In other words, we were stuck using Excel spreadsheets to make decisions then we had to validate the decision and sign off on it as the human who was deciding. Basically, we could build prioritization and tracking "software" out of spreadsheets, but anything other than that, such as the software used to log inspections, had to go through the same process our medical devices went through in order to be used for the design or manufacture of the actual devices. Excel was an absolute life saver there for at least the stuff we could use it for!

Yup. The rule of thumb I learned was that at a FDA regulated facility, "anything that touches the product" is regulated just like it's the product. And when the FDA audits a facility, they focus primarily on software.

Yep, and for one spreadsheet that prioritized some work, we had to show the FDA that the spreadsheet didn't materially affect the devices we were manufacturing. Basically, this particular one just told us which lots of goods to inspect first, so at worst case it would have just slowed down our line, not affected the device's quality. We still had to take 1 hour to walk some inspectors through our use of it, and why it wouldn't fuck things up.

I also started a project to upgrade some software from some old in-house developed stuff to an SAP module (gross, but effective) and it took about 18 months just to make the development and rollout plan, since it was incoming inspection software so it was super important to get right. I left before I saw how long it took to develop, but I think that's the easy part of the whole process.

I don't think I could do FDA software, it sounds so painful. Same with voting machines that are properly regulated (had a CTO at one point who previously did that sort of work and he had stories to tell). Fintech is hard enough.

How many times have people who can write code spent many weeks on something that could be done in excel in an afternoon?

This was (and may still be) the foundation of tax software: domain experts in each province specifying tax formulas in a spreadsheet with an interpreter that takes those formulas and translates it to code libraries in Java, C, C++, etc.

I honestly believe everyone working at a tech company should know or learn how to code even if it's just SQL or basic Python.

I'm more than happy creating some views in a SQL database and give business people access to a read only replica instance so they can do exploratory work on data without much involvement from engineering. I've seen so much developer time spent on generating reports for the business which takes time away from feature development.

And sure we might complain about data scientists handing us spaghetti jupyter notebooks or business analysts giving us rube goldberg excel sheets to productionize but I vastly prefer that over them telling us what they want in words. They are POCs and prototypes. It's fine if they are messy.

So if low code tools are thought of in the same vain as excel or jupyter notebooks, they can be pretty darn useful.

> I honestly believe everyone working at a tech company should know or learn how to code even if it's just SQL or basic Python.

Why? They should already know the native language like English in the US, which is perfectly capable of describing a problem. Unfortunately, many people are poor at communicating in the native language, which is a more fundamental problem. However, how does learning another language like Python or SQL make this any better, if they are unable to use their native language sufficiently?

While I agree that English or any other spoken language is sufficient to describe technical requirements, many people have trouble communicating what they actually want because the language itself is very forgiving and so there is room for misinterpretation.

At least with a programming language, which is more precis e and limited and what you can express, you are forced to think more precisely the desired logic.

I've taught and gave workshops to business people on programming and database query languages for data analysis include non-SQL ones like Mongo. And I can say that those that took to time to learn the query language communicated more effectively because they can send over a query and then use English to give more context, mostly around the presentation layer.

Yep, I'm working with a guy on the business side who is amazing with Dash. It's the best example of a skill set being greater than the sum of its parts that I've seen.

The problem with throw-away prototypes is that often don't get thrown away and become the actual system. 'Hey it works, mostly, why spend money improving it?'.

No tool or paradigm will solve the problem of working for morons.

I spent a couple of years not that long ago basically wrapping a proper production system around a low code system because it had grown so complex by the time I joined that trying to just do a rewrite was not feasible in a reasonable amount of time given our small team. Instead we built two-way sync of the data and built new functionality in a proper system and gradually replaced function by function when we could justify the time cost.

Reply on news.ycombinator.com