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

Busting the 10x software engineer myth

swarmia.com

Post reply on HN
Print view View original

331–340 of 356 posts

Re: Busting the 10x software engineer myth

#331

Post by fuzzfactor »

thinkharderdev wrote: post #144
dijit wrote: post #3

I know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy. Some people like to be present and suck up. But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too. Some of the best engineers I know "visit" bits of code or infrast…

Yeah, this is an important point when thinking about it from an organization perspective. I've been at places where they "only wanted to hire rockstars" which was beyond stupid. By definition 10x developers are rare and are going to have a lot of options when it comes to where they work. So if you depend on some member of the team carrying a hugely disproportionate amount of the work, then you are in for a rude awake…

>you depend on some member of the team carrying a hugely disproportionate amount of the work

This can be a problem when there is only one high-performer.

You hire all high-performers so this is not what happens.

Re: Busting the 10x software engineer myth

#332

Post by fuzzfactor »

mmargerum wrote: post #153
thinkharderdev wrote: post #144

Earlier quoted context omitted.

Yeah, this is an important point when thinking about it from an organization perspective. I've been at places where they "only wanted to hire rockstars" which was beyond stupid. By definition 10x developers are rare and are going to have a lot of options when it comes to where they work. So if you depend on some member of the team carrying a hugely disproportionate amount of the work, then you are in for a rude awake…

The problem I have is they always want me to train someone as insurance for if I leave. It becomes a self fulfilling prophecy when you make me work and train mediocre people. I just want to build great things and be left alone.

If you trained one or more operators who have already left for alternative employment, you could point out that there may now be other orgs making more money from your technology than your own employer is.

Re: Busting the 10x software engineer myth

#333

Post by jjav »

timando wrote: post #328
afpx wrote: post #317

Earlier quoted context omitted.

I've worked with hundreds of average (professional) developers over the years, and I've only met 1 person who was a 3x developer. I've met several 2x developers and lots of 1.5x developers. I assume a 5x developer exists, but I doubt a 10x does.

When your baseline is 0.1x developers, a normal developer can be a 10x developer.

The baseline is 1x, that's what 1x means.

i.e. Your regular professional career developer who does good solid work and is always rated "Meets all expectations". That's the 1x.

Re: Busting the 10x software engineer myth

#334

Post by cyberpunkdyst »

jmchuster wrote: post #308
cyberpunkdyst wrote: post #244

Earlier quoted context omitted.

This is based on my limited personal experience observing the careers of people I know, whom I could consider somehow exceptionally good at their craft. I co-led the CTO team of software consultancy with 350+ devs. In that role it was pretty clear that it was really hard to compete on salary and how interesting projects experts could be offered. Motivations differ based on what the person values. The top motivations…

I would probably consider consultancies very differently from product companies. Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizin…

In my experience the difference between good consultancies and average product companies is not very big. On average I've seen consultancies being able to attract more technically curious and product-minded engineers. The exception are the product companies that are somehow special in the market (e.g. can offer a significantly better pay, or do something very interesting in terms of scale or technologies).

The dynamic you describe tends to get stronger, when consultancies grow. The voices & competence of the technical people becomes less important when it comes to the business and efficiencies in utilization and the company brand start to matter more. The consultancy I worked at was not an incumbent, but an underdog competing with the big players, so the actual execution mattered more, when trying to win bigger customers. Even in consultancies, there are operational effiencies you get from having competent people. Mainly from having less middle management & account managers.

However, there things are useful for the consultancy's business only to a limited extend. You only need to be slightly better than the average consultancy and you're OK. So there is a point, when you either need to be great at sales or thought-leadering, or a consultancy can no longer increase your salary or provide your with work you find interesting.

Re: Busting the 10x software engineer myth

#335

Post by jmchuster »

cyberpunkdyst wrote: post #334
jmchuster wrote: post #308

Earlier quoted context omitted.

I would probably consider consultancies very differently from product companies. Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizin…

In my experience the difference between good consultancies and average product companies is not very big. On average I've seen consultancies being able to attract more technically curious and product-minded engineers. The exception are the product companies that are somehow special in the market (e.g. can offer a significantly better pay, or do something very interesting in terms of scale or technologies). The dynami…

Interesting on that first point, that's not what i would have expected. So what are you seeing from these product-minded engineers that leads them to choose a consultancy over a product company?

For "underdog" consultancies, i've always felt that they win by

1) sending their A team where an incumbent would be sending in their C team. That would make sense, as the incumbent's A team is on a more important client, whereas this small client "is" the underdog's important client.

2) carving out niches and specialties. So you serve less clients and projects, but also build up a reputation. You kind of become an incumbent of sorts, just for that niche.

Re: Busting the 10x software engineer myth

#336

Post by goto11 »

cies wrote: post #301
goto11 wrote: post #106

Earlier quoted context omitted.

So what happens if you divide by 0 in Elm?

You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular. Maybe time to study some of that "hipster stuff". I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).

I'm not knocking Elm at all, I think it is a very interesting language.

I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away.

A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite.

If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.

Re: Busting the 10x software engineer myth

#337

Post by goto11 »

cies wrote: post #302
goto11 wrote: post #150

Earlier quoted context omitted.

I'm sure Elm is a great language, but thinking it eliminates runtime errors is ridiculous. Of course it might eliminate exceptions , but exceptions are not errors, rather they are (sometimes) signals than an error have happened.

Yes, this only holds for some definition of errors. Run time program errors due to type mismatch, nulls and exceptions are non-existant. Pretty cool!

The question is, why was these run time error not caught by unit tests? Probably because there wasn't any tests - which means the code likely have numerous logical errors. Static typing is great, but it will not prevent against logical errors. So without testing you will have bugs in any language you rewrite in.

Re: Busting the 10x software engineer myth

#338

Post by denton-scratch »

deltree7 wrote: post #322
denton-scratch wrote: post #280

Earlier quoted context omitted.

10x what? As far as I'm aware, Shannon wasn't even a programmer. I'm sure Ritchie was pretty good at coding in the language he invented; AIUI, that language is pretty similar to the assembly language of the machine he designed it for. I don't know anything about Buterin and Dean. I'm sure these people all had brilliant ideas and insights, that I couldn't begin to match. But given an arbitrary dev task, I doubt they'd…

'dev task', 'shannon wasn't a programmer', 'don't know about buterin, dean' -- There in lies your problem, seriously

Shannon was a mathematician, famous for his work on information theory. Wikipedia says he presented a paper on the subject of programming a computer to play chess. In 1949. It doesn't mention any other programming accomplishments. And as far as I know, there were no programming languages at that time.

And if my "problem" is not having heard of Buterin and Dean, I reckon myself a fortunate fellow - I can think of worse problems.

Re: Busting the 10x software engineer myth

#339

Post by AtlasBarfed »

mikepurvis wrote: post #325
AtlasBarfed wrote: post #294

Earlier quoted context omitted.

Side scrollers have existed since the Apple II on "PCs". I highly doubt that 1991 was the first side scroller on ibm pc. Wolfenstein was not the first 3d fps on ibmpc, and certainly not in "PC" land. Skyfox existed on the Apple II, and battlezone likely was ported at some point. Carmack was fantastic, but again his "requirements" are static and he is a dev team of one.

A lot of early jump & run games worked on a screen-by-screen basis (Prince of Persia, Lode Runner, etc) rather than actually having smooth, NES-style scrolling. In any case, this Wikipedia article [1] backs up that the only real predecessors of Keen on PC were early-80s console ports that were extremely limited in other ways, like having boxy, low color count graphics. [1]: https://en.wikipedia.org/wiki/Side-scrollin…

seadragon on the apple II did scrolling, as did a lot of shmup and shmup ports.

I've never written a side scroller so I don't know how much of the gravity/platform mechanic complicates the scrolling, but I imagine it's about the same thing as shmups with hitboxes, sprites, etc.

Re: Busting the 10x software engineer myth

#340

Post by carnitine »

goto11 wrote: post #336
cies wrote: post #301

Earlier quoted context omitted.

You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular. Maybe time to study some of that "hipster stuff". I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).

I'm not knocking Elm at all, I think it is a very interesting language. I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away. A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewr…

It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.
Post reply on HN