[anonytrary]

This is a simplistic reduction of what many senior programmers do. In my experience these so-called "jiggle programmers" are ones who actually ship code and meet business needs. Sometimes that's what we're looking for. We don't always want a fresh grad who is keen on implementing a completely useless system from scratch. We need people who ship.

[hedora]

This is why it's important to figure out what your core expertise is.

If you're copying and pasting your core expertise from stack overflow, then, I hate to break it to you, but you'll never successfully differentiate your product.

[anonytrary]

I'd wager that 90%+ of "tech" companies are hiring software engineers to "solve" technical problems that have already been solved in order to solve business problems that have not yet been solved.

Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.

[q-big]

> Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.

If this was true, it would bring a significant economic advantage to a startup if it would not use leetcode style questions for job interviews, but instead ask hard questions about these textbook architectures.

[YZF]

But someone might be able to answer the questions but not be able to build stuff. The coding portion of an interview is supposed to answer the question "can they code". If they can't code I don't think they can work in either domains (reapplying an existing technical solution or inventing one that doesn't exist). I'm not a fan of some styles of coding interviews but writing code needs to be part of any interview for a software developer (+ a lot more).

[manigandham]

Writing code in an interview is not the same as the "leetcode" riddle questions that the parent poster was talking about. It's usually esoteric language and computer science concepts that are not very relevant to the job role.

[BossingAround]

Ah yes, because innovative software products invent new coding paradigms, which is exactly how they get to be so popular. That makes sense.

[raxxorraxor]

I solve problems with software and I do both. If I can copy something it is most often smarter to do just that. There is not only copying code or writing it yourself.

Find the most readable color of a font for a given background on most displays. You could do extensive research on colors for something that on the first look sounds rather trivial or find a very thoroughly worked out solution on stack exchange.

It is difficult enough to advertise self-made software when many people are looking for off-the-self solutions. So being fast and therefore affordable is quite important.

I mostly develop for embedded systems on custom hardware so ready to use solutions are rare. But if I want to visualize process data in a browser? Please give me all your thousands of dependencies Javascript.

An algorithm I implement from scratch? Very rare. This takes time and thorough testing compared to something that is already solved.

[smsm42]

May be true, but there is a lot of work for people that know how to cross t's and dot i's and don't need to differentiate anything, just successfully implement known solutions for known problems for N+1'th time without reinventing the wheel and messing anything up. It's not a glamorous work and probably won't make you neither a billionaire nor a CEO of a trillion-dollar unicorn startup, but there's no use denying it exists and somebody has to do it too. And if that someone won't mess up too often, they can earn their living very well.

[mschild]

I think the big differentiating factor will probably be that "jiggle programmers" don't really know what they're copying or why something works. I'd hope senior programmers do.

[paulryanrogers]

We all jiggle a bit as we rarely have time to work through APIs and their dependencies down to the sand used to make the chips.

Though I'd agree that no engineers should be copying code without understanding its intent and interfaces.