Comment by ryandv | Hacker News Reader

Comment by ryandv | Hacker News Reader

Parent Full thread

The point is that society elevates symbols to a level of importance above and beyond the things those symbols are supposed to refer to.

Thus people valuing the symbols of professionalism over actual engineering prowess; LinkedIn profiles over the person themselves; and LLM output over a human's actual thoughts.

Despite this person self-evaluating as having regressed in their engineering skills, all the outward status markers that are supposed to represent outstanding achievement are still there, and project a persona that is not congruent with the author's own self-image.

Worse yet, you must play this game of smoke and mirrors because you are "only seen when [you] do the fake crap like update [your] LinkedIn to celebrate 1 year at $FAANG."

This also reduces the signal/noise ratio when posers begin aping those same status markers in order to represent expertise where none exists. If you want to experience this directly, I suggest you attend some networking meetups and talk to the newer blood in the cybersecurity industry. Not exactly DEFCON 10 any more.

And a common blind spot around good software engineers is that software is the hammer for all nails.

Someone recently asked me if Mark Zuckerberg was a good engineer. I think the answer is a very, very qualified "yes." He knew enough to bash together a prototype in PHP of a social network site. But he was a very good problem-solver; he managed to find a tool space people found use in, and iterated on it until it got so good it dominated lives and became the primary communication solution for millions of people. He also knew enough about people to hire the right folks to do the hard (and tedious; the tedium should never be ignored) work to turn his prototype into product, scale it, and maintain it. And that's every bit as much problem-solving as implementing a breadth-first search to populate a "People you might also know" list.

He didn't need to have Knuth's Art of Computer Programming memorized to do what he did.

Software engineering (and the software it creates) are tools. They give us pleasure to use also. But the tools and the pleasure can become disconnected from what gives other people utility and pleasure without some heads-up checks from time to time.

To put it more succinctly: businesses want to hire people that will help them make money. The ability for a programmer to make money for a business is not as tightly bound to perfect code and passion projects as this person, and many programmers, think.

I don’t like this definition of “good engineer” because it seems degenerate with “good businessman” or “good product designer.”

He was a bad engineer: early implementations of Facebook were buggy, insecure, and not featureful. I agree that engineering is not valued in-and-of itself generally (it is just a tool), but instead of turning it into something inherently valued by changing the definition of it, we should just admit that it isn’t valued in-and-of itself. I mean, in all fields (other than some art, maybe) the end result is valued more by outsiders than the process to get there…

He successfully pushed a product out that worked well enough to get traction and get popular.

Part of good engineering is knowing what problems to solve. Facebook early version was buggy and insecure and lacked features. And none of that mattered to the target audience enough to not use it; its value outweighed the pain points. A junior engineer can solve today's problems; a senior engineer can build against tomorrow's, and a staff engineer knows what problems should be solved and what shouldn't because time is a finite resource. The further you go up the ladder, the fewer problems can be solved by throwing the right algorithm at it with your programming tool of choice.

A dreamer and a hobbyist can put together a well-crafted site with five users. An engineer keeps working at solving the problems between there and five million, including solving them by building the systems to solve them and finding the people to work in those systems.

Under this definition the best engineers seem to be sales guys.

At the places I've worked, sales guys get some say in prioritization of features, but rarely in prioritization of their implementation.

I would say the distinction is good sales guys can turn market sentiment into a feature request, good engineers can turn one or more feature requests into behaviors in the system.

But the actual truth is that a sales team with some idea of how software is written coupled to lead engineers with some idea of market sentiment and taste is more powerful than either discipline heavily siloed.

>I suggest you attend some networking meetups and talk to the newer blood in the cybersecurity industry.

Not familiar with the industry, has cybersecurity taken a turn for the worse in some way?

Reply on news.ycombinator.com