A code can be converted to a low code. A low code can be migrates towards no code.
That's an ideal world scenario. These platforms and other platforms out there are heavily tightly coupled between front-end and backend hence making them unclean.
Why unclean? Migrating a code based builder(IDE) to a low code based builder (GUI with confoguration) to a no code based builder (DRAG AND DROP) ultimately towards design to code builders.
Unfortunately there isn't any.
Here is how I made my statements above.
An app is a giant state of rectangles of content with show or hide configuration. Each state is followed by an user interaction.
Now the problem is reduced to a UI.
How about building an UI that builds UI?
I have few things documented in past commits of my project called ui-editor.
I stopped working on it publicly due to time consumption of new commits. You can find the wiki or the read me in pat commits.
My opinion, those products don't scale or not maintainable in long run. Because those apps or the builders are code based. To have a clean solution! The builder should be a no code in first place.
From my view this is neither predictable nor stable as mentioned by OP. I can't imagine how this can be "boring". I think boring also means not making decisions with impact
You don't have to act dumb (and you shouldn't). You just have to not act like a "rock star". The most brilliant devs I've ever met were people nobody would call "rock stars". They were collaborative team players.
This, exactly this. I know so many people who are "above average" developers that I would love to work with because they are nice, collaborative people that are a joy to work with. The biggest problems we've faced are with these so called "10x developers", who do get stuff done, but are a total pain in the a* to deal with!
A developer that knows how to treat other people in the team, knows how to be professional, works on what they agreed to during sprint planning, doesn't want to rewrite the project to a new technology and doesn't want to create their own cool project because they know the ultimate goal is to ship to users, doesn't react badly to criticism, is not unreasonably stubborn, has good hygiene, doesn't take code reviews personally and agrees that management has a necessarily different point of view from pure developers.
A brilliant dev is one who consistently produces solid and feasible solutions to difficult problems, in a timely way.
A more enlightening question is "what is a rock star" in my mind. A rock star is a dev who truly believes that they are the smartest person in the room, who looks down their nose at any work they didn't produce, who is only really interested in things that they think make themselves look better rather than things that will actually help produce the best end product possible, who insists on using the whatever latest shiny thing is in fashion over less shiny but more appropriate approaches, and so forth.
The Rock Star will say, “I will do these 10 things by next Friday.” And then next Friday rolls around and 8 of them are done. This repeats week after week, but I can never tell which 8 will get done. They’re boastful and proud that they got a lot done but the rest of the team can never count on them to get any specific thing done.
The other person will say “I will do these 5 things by next Friday.” And then next Friday all 5 are done. And they repeat this week after week after week.
I agree with your scenario, but I wouldn't consider someone who consistently under-delivers a "rock star."
This is why defining terms is important. For me, a rockstar is a developer who is just further along, who likes to program in their own time, who reads Hacker News, and builds projects on the weekends.
Within 5 years, that person will be much further ahead than the rest and will spot pitfalls, security, and performance issues simply because they have encountered them before. However, sharing that information could lead to that person being called a "rockstar" and problematic, hampering "progress".
There is a difference between acting dumb and being a know-it-all.
Someone recently left my team who was a rock star in his own mind. He claimed to know it all, and would go on and on about how everyone else should do their job. The reality was that he didn’t understand the complicities of the issues, any time a team was involved he would try to delegate everything away, anytime there was an issue he was the first to finger point, any time something was difficult he would quit while making excuses that it was not his fault, he only knew one language/framework and saw no reason why anything else would ever be needed/wanted… I could go on.
I’m sure he might sound great in an interview, as he loved to talk himself up and talk about how amazing he was and how stupid everyone else is. In the real world, he was a toxin within our team and no one was sad when he left.
I’m not sure how one would separate a true “rock star” from a delusional wannabe in an interview, other than having a well tuned BS meter.
There is a big difference between acting as if you know something and actually knowing it. You're describing one thing, while the comment you are replying to is describing something else.
Let's consider a developer who is interested in programming and has a lot of experience. If the team is going down a path that the developer knows will lead to issues, or if the developer tries to help because the team is not as strict and it's leading to outages, that developer may be perceived negatively.
However, the developer is able to find security issues and potential bugs during code review, objectively providing significant value to the team.
This developer could be labeled as having a "rock star" attitude, while in reality, they are trying their best to ensure there are no security, performance, or outage issues.
Keep writing. Write without intention. Over the years or days or months or weeks you will notice the pattern in your writing. It's a reminder that outside is disorganized, but on your brain it's pretty organised.
