Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to be a -10x Engineer

taylor.town

Post reply on HN
Print view View original

471–480 of 514 posts

Re: How to be a -10x Engineer

#471

Post by pkolaczk »

whateveracct wrote: post #322
jay_kyburz wrote: post #288

Earlier quoted context omitted.

Now, every time you hire an engineer they need to spend weeks or months learning Haskell on top of everything else. It now costs the business an extra 50K every time you get a new developer. I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.

There are more costs than onboarding costs. Also it's not hard to hire Haskellers or Haskell-adjacent devs. Haskell in fact makes you stand out. Those sorts of people don't need months. I've seen people new to Haskell make their first commits within a week. And they weren't geniuses or anything. But they also didn't have an attitude about it.

I guess the problem with Haskell is not really hiring, but it is simply a very hard sell to people without academic background. Haskell is for sure elegant, and has some cool features, but this is too little to get wide adoption.

Seriously, what important industrial problems does it solve? Explain it to me like to a manager you met in an elevator. If you say e.g. lower bug rate, then be prepared to show some evidence (and no, please don't compare it to Python or other dynamic languages).

Re: How to be a -10x Engineer

#472

Post by mesozoic »

flumpcakes wrote: post #40

> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…

The important part is that you do it for something that's not all that important then make sure to get the project dumped before any real progress is made.

Re: How to be a -10x Engineer

#474

Post by mlyle »

goblin89 wrote: post #451
JohnFen wrote: post #313

Earlier quoted context omitted.

"Rewrite it" is almost always the wrong answer, although it can be an overpowering instinct. Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths: 1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me. 2) If I embark on…

I find the argument against rewriting to be like the DRY principle: an oft-misapplied rule of thumb causing much of the unwarranted complexity in software around us. Truth is, the cost of “just rewrite it” is as large as your unit of software architecture. Prefer loosely coupled, cohesive small parts and rewriting to accommodate changed requirements becomes preferable to the alternatives that tack on complexity as la…

> Truth is, the cost of “just rewrite it” is as large as your unit of software architecture.

Often, you pick "just rewrite it" when the complexity of a module seems to have grown too high and refactoring to reduce complexity or to hit new objectives seems difficult.

The problem is, a lot of that complexity there may be necessary because of subtlety. Or, we may not do all that much better the next time around.

There's a strong bias in software engineering in particular to underestimate inherent difficulties and overestimate our own capabilities. Sometimes a rewrite is a win, but this bias causes us to select rewrites in times when it ends up not being son.

Once bitten, twice shy.

Re: How to be a -10x Engineer

#475

Post by robertlagrant »

bstpierre wrote: post #406
ryandrake wrote: post #277

Earlier quoted context omitted.

Almost every software company I've ever worked with had this insidious "priority inflation" that couldn't be stopped. It works like this: We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "pro…

I worked at a shop with P0, and then there were too many P0 tickets, and then you just worked on whatever the CTO told you was the _actual_ highest priority ticket when he stopped by your cubicle for a chat.

No one got fired for making something a P0. That's the problem.

Re: How to be a -10x Engineer

#476

Post by ptx »

danaris wrote: post #456
ptx wrote: post #349

Earlier quoted context omitted.

It seems like a good rule of thumb though. Here's a diagram of the 11 different tools you need to study to create an installer with WiX, which takes literally thousands of lines of XML: https://documentation.help/WiX-Toolset/tools.html By contrast, WiX# provides a complete code sample that specifies a complete installer in less than 20 lines, with no diagram necessary: https://github.com/oleg-shilo/wixsharp

You seem to be arguing that the existence of one bad diagram and one (related) good text explanation proves that, in general, needing a diagram is bad, and being able to explain something succinctly and clearly in text proves the merit of the thing being explained. I...do not feel that this follows in any way, either as an absolute or as a rule of thumb.

In my personal opinion as a user, usage of WiX is extremely complicated (requiring multiple different tools, thousands of lines of XML, understanding of the incomprehensible MSI database format as well as the multiple levels of inscrutable macro substitution WiX puts on top of it, and so on). The documentation presents a diagram of the 11 different tools involved (which I'm not saying is a "bad diagram").

Usage of WiX-sharp (which wraps and hides the mess decribed above) is so simple that a complete sample project is just a few lines of code, as shown in the README. There is no diagram because none is needed.

This is consistent with (but doesn't prove as a general rule) the idea that "if something is so complicated it can only be understood with a picture, it's too complicated"

Re: How to be a -10x Engineer

#478

Post by quickthrower2 »

solarkraft wrote: post #328
perceptronas wrote: post #138

Earlier quoted context omitted.

Its extremely hard to argue for debuggability. I always try to prioritize how easy is it to test the said feature and understand it. However, during reviews of other engineers PR, I am always met with criticism that there is no need. "Instead of localhost, this can be tested on staging" and etc.

Debuggability is a top factor for how long development will take. How is it hard to argue for?

Only for developers who want to thoroughly test and check their work.

Re: How to be a -10x Engineer

#479

Post by ngc248 »

donkeyd wrote: post #203
safety1st wrote: post #97

Earlier quoted context omitted.

Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer w…

I had a -10x engineer in my team. They refused to test their own work, because that was the tester's job. They sometimes implemented a feature in the wrong place, both technically and functionally, requiring a complete rewrite (and removing code, roll-back was not an option in this tool). They started using float in HTML while we used grid, this caused stuff to be on top of each other. Unfortunately, this guy played…

I call them 100x engineers, since they create 100x more work for others

Re: How to be a -10x Engineer

#480

Post by sshine »

nickpeterson wrote: post #19
sshine wrote: post #6

Earlier quoted context omitted.

> the rest of the business is completely illiterate about anything even slightly technical It is that moment of realization that you're entirely responsible for the fate of the company, and you either think "I better tread carefully" or "This should be rewritten in Rust."

Rust may still be a bit too pragmatic, perhaps you could use a language you wrote yourself?

Yes, I've heard Rust has a high learning curve.

By making things in your own language, you stay ahead of the learning curve while others stay perplexed.

Post reply on HN