Hacker News new | ask | show | jobs
by _omnf 1777 days ago
I love no code! Wait. Wait. Hear me out... Building software is easy. Changing people's minds is damned near impossible.

As an engineer:

- I'm constantly handed shitty (or a complete lack thereof) requirements from non-technical people. No code lets people figure out that they haven't thought something out nearly as much as they think they have. I no longer am the bearer of bad news.

- I constantly see business people undervalue the design process or skip it all together. No code is making non-technical people realize that they have to plan out before they just throw engineers at a problem.

No code is changing the dialog around this. I see that as a net positive. Of course us software engineers know the problems around no-code - we'll deal with them as we deal with all problems.

10 comments

> I'm constantly handed shitty (or a complete lack thereof) requirements from non-technical people. No code lets people figure out that they haven't thought something out nearly as much as they think they have. I no longer am the bearer of bad news.

Personally I find this to be part of the Job. The way I look at it i'm the one looking at sites all day, I'm the one caught up on all the latest trends, I'm the one who knows what looks good and what doesn't. My client on the other hand, they will likely know what they want, but when it comes to describing it, they may offer a nebulous response.

My job here is to take that nebulous response and form it into requirements. One thing I do all the time is if a client asks me to do something on the site and I can't discern what they want me to do, I will usually ask them where they go the idea. They will say something like "Oh pinterest, instagram, facebook, etc have something like this", we pull up that site and they show me, and from there I adjust requirement accordingly.

I don't hold this against any of my clients, it's ok if they don't quite know what they want, I'm the professional and it's my job to figure that out.

In one sense I agree with you. I find it enjoyable to take an idea and to flesh it out, breaking down the different parts.

What I don't find enjoyable is when clients don't have the budget for their grand poorly thought out ideas and refuse to accept a solution which will get them 90% there with 1/10th of the effort.

don't you have a project manager that acts as an intermediary between the customer and the coder?
I agree entirely with you, except.. i don't mind the design process (or lack there of) you describe. I feel i get paid for it.

I'm in a smaller org and yea, the product team definitely skimps on plenty of details. When i have to point out drastic UX flaws or impossibilities it is definitely frustrating. However i legitimately think that is what they hired for. They wanted someone (well, a team of devs) to deal with this stuff. To be the architect of their general direction.

The bigger question to me is if the positions we have that more traditionally handle a more complete design.. are they being overpaid in our org? I don't think i'm being _underpaid_ for my architect + dev hat, but i do wonder if someone else is also being paid for architect but i'm cleaning up for them lol.

I've also found that the designers seem to.. for better or worse, take what you give. I notice they give me a far more loose definition than they give less experienced devs. I suspect this is because they expect/trust me to follow through, and i do - but this also effectively takes "advantage" of what i offer. I use quotes because i also get paid much more than the other devs i speak of, so i go back to what i said earlier, i think i get paid for this.

It's frustrating. But i also enjoy it a bit. If they laid everything out perfectly i'd be left with just writing the correct design patterns in code, using the right data structures, etc. Worse yet i wouldn't have the ability to shape the UX for better performance. I dunno, all the companies i've been at have been like this. I don't feel it's unique, but maybe it's just how i put myself out there.

> the positions we have that more traditionally handle a more complete design.. are they being overpaid in our org?

Probably, depending on the size of the org. There are lots of places for semi technical people who sort of know what they’re doing, but don’t really provide value, to hang out in a large and growing enterprise sales org. They can collect what I believe are reasonable salaries and just route between the engineers on the customer side who actually know what they want, and engineers on the provider side who can actually provide it.

Any giant coupling between an application and platform ends up looking like this, I.e. pick your favorite Fortune 500 company and their cloud provider, security engagements, hardware vendors etc.

> I don't think i'm being _underpaid_ for my architect + dev hat, but i do wonder if someone else is also being paid for architect but i'm cleaning up for them lol.

Yep. I made a joke recently that in companies that have a formalized promotion process, if you apply for promotion and are denied, one of the consolation prizes should be that you get to apply for someone else to be demoted. I jest, but sometimes it feels like that would be just as helpful and fulfilling.

Great point! It's scary how little thought people give to this.

My all time favourite was when I made a news portal for a trader who wanted to create a hub around the commodity he was trading.

It was mostly customized drupal with a few tweaks he desired, and roles for writing/reviewing/members.

Come demo time he was upset there were no news articles in his "news portal". At first I thought he wanted more lorem ipsum content to see what it would look like. But no, he really expected that I would also have written the initial news articles for his website.

What if he meant having the news related to his commodity delivered via some news API?
I had a tech-savvy friend want to build an app but the project wasn't very well defined. After a short period of angst I suggested that he build an MVP in Bubble and that I could step in to work on any integrations that needed code support. It worked exactly as you said.
Thank you. HN is one of the few places where no-code is discussed at length, and it's frustrating how many programmers default to replying with "I would never use this in production."

You don't have to. The no-coder is building a prototype, safely sandboxed away from your precious CI/CD pipeline. The benefit of building a robust prototype is that the idea-haver person doesn't bother developers with unfinished requirements, and the developers don't have to write a damn thing until they look through the prototype and start mapping out some changes.

No-code is going to be used in production for sure. It's not something only for sandboxing and prototypes.
My point is that the conversation about such tools is derailed by HN programmers who automatically jump to the conclusion that these products are the wet dreams of non-technical CEOs, who will force their org to go no-code exclusively.

If no-code tools are used in production, that implies that it will have to pass QA and code review, just like anything else.

Completely agree with the sentiment.

But the definitions for both "production" and "application" are not so black and white. Take a super simple no-code app like a Google form survey. Some people would argue that that is not an app, others would say it is. Is it production? If I send that around to my team of 10 people, there will be no code review or QA. If I send it to 200 customers, then of course I let someone else review it.

Just wanted to let you know that these are very good points and you've changed my mind about no code.
It's great if it stops at dialogue and they don't force you to stay on the no-code platform.

It kinda sucks we need to develop products to convince people that hired us that we might know a thing or two about building software

Can you elaborate on the list of problems with no-code? Of course I'm not denying there are problems with no-code, I'd like to learn about other developers' issues, particularly with larger, longer-term projects.
No-code eventually becomes so complex that it becomes a bad programming language eventually, or lacks the expressiveness of a programming language to do what the business wants.

The imagined problem no-code addresses is business people thinking that their requirements are simple, and the source of their problems are expensive software developers and programming languages. Just get a junior business analyst to drag some boxes around, and job done. They are wrong.

This pattern has been repeated for decades now.

I think there's an interesting analogy to be drawn with Lego. You can build interesting and useful things out of Lego, more than you may even realize. It can be fast & effective, it's certainly easy, especially if you imagine we've abstracted away the question of what bricks you have so you have as many as you need of any kind & color.

However, you end up with two sorts of problems if you start letting people just build solutions to whatever they like with Lego:

1. The solutions may work, but they aren't really that good. You can only do what there's Lego bricks for. When it comes time to solve the problem at the next level, the Lego stuff can be less helpful than it looks even as a prototype, as even at small scales a lot of the engineering in the Lego was solving around the limitations of Lego in the first place, rather than solving the problem per se.

2. Eventually you get people trying to build sheds and houses out of legos, struggling to put up shelves, all kinds of silly things that the solution isn't really suitable for. And there's a variety of pathologies here, too, like how they don't understand why their Lego solution isn't good enough, and why you can't just buff up their shelf since it's just that the shelf is falling over, and explaining to them that they basically just built a shed that is made out of code violations may not be very easy, etc.

There are advantages, too, like letting them get their hands on some engineering and stuff, and there are a lot of problems in the world where a Lego solution is no big deal. I don't know if I've got anything right now, but I've done it before; I had a lego setup for holding tablets & phones for charging that was better than anything I've bought, because it actually had the correct sizes for things, for instance. But there's limits.

Ultimately no code will require "code" for a real robust production app.
And at that point all of that no-code turns from an accelerator into a giant pile of legacy crap outside of your control which will cause you to hit a wall of ability to evolve the software far sooner than later.
The primary problems with some no-code platforms are:

Access to the code base - it's hard to build on top of, or around the platform

Long-term viability - if i build my company on top of your product, how can I be sure you'll always be around?

For transparency, I am the cofounder of Budibase: https://github.com/Budibase/budibase

most obvious would be you are building your business on rented land and could be deplatformed at any time plus strong armed into extreme markup prices with no leverage against the platform.

The other issue is that it seems doubtful the product could scale beyond a certain level in terms of traffic and also employees collaborating to add features

You made me laugh so hard as just yesterday I was re-watching 'The Expert' on youtube[1],just always hit close to home. Mylanta, try designing a Logo for a business, or website, or front/back-end, or apps... I think it's the customer never knowing what they really want that's the common denominator.

[1] https://www.youtube.com/watch?v=BKorP55Aqvg

> I'm constantly handed shitty (or a complete lack thereof) requirements from non-technical people.

My solution to that is that for every missing requirement I will make own personal decision and fill the gaps as I see fit. If that’s not what they want then the development window is extended to incorporate changes and refactoring. I am not going to work late or stress over deadlines because that isn’t my failed delivery and it is working as designed.