As someone who spends time programming, I of course find myself in conversations with people who aren’t as familiar with it. It doesn’t happen all the time, but these discussions can lead to people coming up with some pretty wild misconceptions about what programming is and what programmers do.
- I’m sure many of you have had similar experiences. So, I thought it would be interesting to ask.
Function/class/variables are bricks, you stack those bricks together and you are a programmer.
I just hired a team to work on a bunch of Power platform stuff, and this “low/no-code” SaaS platform paradigm has made the mentality almost literal.
I think I misunderstood lemmyvore a bit, reading some criticism into the Lego metaphor that might not be there.
To me, “playing with bricks” is exactly how I want a lot of my coding to look. It means you can design and implement the bricks, connectors and overall architecture, and end up with something that makes sense. If running with the metaphor, that ain’t bad, in a world full of random bullshit cobbled together with broken bricks, chewing gum and exposed electrical wire.
If the whole set is wonky, or people start eating the bricks instead, I suppose there’s bigger worries.
(Definitely agree on “low code” being one of those worries, though - turns into “please, Jesus Christ, just let me write the actual code instead” remarkably often. I’m a BizTalk survivor and I’m not even sure that was the worst.
My take was that they’re talking more about a script kiddy mindset?
I love designing good software architecture, and like you said, my object diagrams should be simple and clear to implement, and work as long as they’re implemented correctly.
But you still need knowledge of what’s going on inside those objects to design the architecture in the first place. Each of those bricks is custom made by us to suit the needs of the current project, and the way they come together needs to make sense mathematically to avoid performance pitfalls.