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.
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.
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.
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.
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.
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.
If no-code tools are used in production, that implies that it will have to pass QA and code review, just like anything else.
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.
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
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.
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.
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
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
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.
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.