Woo for Its Own Sake
I had a few job interviews last year where it was clear the people trying to hire me had plenty of programming talent on board already.  They were just looking for a technically competent adult who could look at what was going on and figure out why all the fancy work that was getting done was not doing what the rest of the company needed and expected.<p>One company had several different teams of programmers that were great at building things, but they were all going in different directions with different tech stacks (two in Go, one in Rust, and one in Python) and completely different data models for the company&#x27;s basic business domain.  When a directive came down from above that two systems HAD to be integrated, because a customer paying for one product wanted the other one as well, as sales and product had been hoping and planning since before the products were built, the engineers gave them an estimate of four months to do the integration.  The business knew that meant 8+ months.  How many programmers did they have to get this disjointed?  Less than twenty.<p>Lots of other companies have similar stories.  I disagree that it is about lack of financial compensation.  These companies were paying good money, and their engineers were living comfortably and abusing the relationship, whether wittingly or unwittingly.<p>Anybody who reads HN can whip up an impressive, Netflix-blog-worthy design for any problem their company has.  If their company is unlucky, they might even have the energy and raw hacker ability to get it mostly working.  Where we&#x27;re failing as a profession is in educating people that this is poor engineering, that it&#x27;s bush league bullshit.  It isn&#x27;t impressive.  It doesn&#x27;t show any ability except a certain amount of shallow raw intelligence, which is necessary and valuable, but which is more like raw material to build ability out of than ability itself.<p>In other forms of engineering, the culture is very clear:  simplicity is an achievement.  Solving an easy problem with a big, expensive solution is not an achievement.  It&#x27;s unskillful.  The best engineers come up with solutions that make you see the problem as an easy one.  Solving easy problems with difficult solutions proves you aren&#x27;t qualified to take on the problems that need those solutions.  How do we establish this as a standard belief in software engineering as well?