Desingineer – the mythical person every startup is looking for

Except this is a discussion in text. Sure, yes, walking and talking are two different things, but how else are you going to know what point of view someone is speaking form unless then tell you in their comment? No reason to assume people are just tooting their own horns for 'hn-cred'. Does your comment mean so little you'd ruin it by belittling people?

As for the rest of your comment: to be fair, from the sounds of things, your still very much new to all of this. You are a junior developer, and that's nothing to be ashamed of. The problem is you are looking at these startup rockstar job requirements and deciding for them. That doesn't mean you are ready, but you shouldn't be the one to decide that. After all, good companies are always looking for good people. And while that position they have posted might not be right for you, they might have another place for you.

> this is why so many junior level people decide to build their own companies

Maybe. I don't know, personally. That being said, though, is that starting your own company requires another "rockstar" requirement list all it's own. Don't fool yourself.

If you're put off by "startup rockstar job requirements," starting a company won't be any easier.

"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

When the organization structure of a project is 'there's just one guy who does it all', the software architecture will tend towards 'the big ball of code' pattern.

However, if the team on a project has people who are engineers, and people who are designers, then a designineer might be a useful product manager to help balance conflicting engineering and UX requirements.

In a startup, looking for a first hire engineer, you probably want someone who will grow into that role - but it's a mistake to have your first system built by them and them alone, because you'll almost inevitably wind up with a big ball of code.

In general, all software should be built by at least two people collaborating, to force some division of responsibility, which will (via Conway's Law) force some structure.

(as you say, the best developers are disciplined and capable of structuring systems in the absence of a forcing structure. This is maybe because they divide work logically into units, and therefore find themselves collaborating with their past- and future-self, giving the structural effect of team work. But apply pressure to even a great developer and that discipline can break down.)

Also goes without saying that the companies looking for this person also will typically be requiring mastery of cross-platform application design simultaneously targeting most every known desktop and mobile operating system; a long, specific list of diverse technologies at very particular version numbers; they should be willing to relocate at their own cost, with remote work and telecommuting unacceptable; and of course they should be willing to work for less than market rate for a practitioner of even one of the skills they are supposed to be masters of, which should be no problem since there is a low cost of living in the obscure one horse town they will be moving to but which features lots of outdoor activities and family values as long as you don't mind the rampant small town corruption, house break ins, ATV, copper wire and catalytic converter theft, weekly stabbings over a girl, and pandemic meth addiction.

I remember reading Scott Adams's advice on how to get into the top 1% (well, reallu the top .0..1%). One way is to be incredibly good at one thing - like Roger Federer. The other way is to keep combining interesting and related things until you're there - ie., someone in the top 10% at coding, design, sales, biology, and construction.

Here's the thing - recently, we've been discussing the willingness of companies trying to hire to accept "false negatives" because the impact of a bad hire is so detrimental to a team. But I think a lot of "false negatives" may be coders who do pretty well in the interview but not quite well enough to get past the filter. The interview process almost never gets at their other skills. So the company fails to hire someone with exceptional domain experience and good design skills because he or she struggled a bit finding cycles in a linked list.

There are solutions for people like this. One is to be a founder - get an idea, start coding and designing, create an initial app, and see what kind of traction you can get. The other is very similar - you'll managed to get hired somewhere eventually, and you can start proposing projects. Eventually, you'll get to run with one, and you can be entrepreneurial about it (well less upside but at least you'll have a salary).

It's much easier to do this on your own or once you're established with a company. It's tough to get this across in an interview process.