Comment by mugsie | Hacker News Reader

Comment by mugsie | Hacker News Reader

Parent Full thread

> I see you are focusing too much on your own problem space

I have worked in many problem spaces, and what I have said stands for all of them.

> I agree that 10x engineers can't fill that role since you can't get a steady supply of them.

10x engineers definitely can, just not Lone Ranger style mavericks that poison teams, or "replace teams"

> Then it is better to have an extremely good team build a good solution

I 100% agree. key work in that sentence is team

> However in an environment where you are writing solid libraries which are not meant to break or change much and therefore wont need much maintenance the requirements are very different. Then it is better to have an extremely good team build a good solution once and then ship it and then mostly leave it alone.

Very little code these days is write, compile and ship once. Compilers, runtimes, interpreters, base libraries, kernels, OSes, CPUs, and tooling all change. Unless you are deploying to a main frame that is slated to run for the next 40 years, all of these changes require updates to code, and that isn't even accounting for security issues (how many companies do you think were frantically trying to recompile programs with retpoline mitigations? How many "run once" pieces of software had to be recompiled with updated OpenSSL after Heartbleed?)

> ignoring that some developers can be vastly more productive is therefore counter productive,

So is discounting the harm they can cause, or the opportunity cost of them not lifting up their teammates.

Let me explain what my job is at Google:

I work in a larger team, but I always solve problems alone. When others have failed to solve something important they give it to me, and I always solve it quicker than them putting a team of staff-engineers on it would. Often my solutions are good enough that they make the whole team pivot in a different direction since it solves many problems for the wider organization. I often design new architectures in doing so, build frameworks etc which others then use.

Note that I am relatively new on the team, so it is not that I designed things which others don't understand. Instead I came in, started fixing a lot of shit and my responsibilities just grew. The most senior engineers on the level of senior directors noticed that I could fix a lot of things others couldn't so I get tasked with solving large problems which are blocking a lot of other efforts. Almost always it involves cleaning up bad architecture and implementing something which allows us to solve more problems. There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me.

Would you say that having me on the team is bad? Am I toxic? I think I wouldn't fit into a lot of teams, but I still think that I can help a lot. If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done.

> Would you say that having me on the team is bad? Am I toxic?

Without knowing you, or your team, I can't know. I have worked with people like this before, (and done it myself on a few teams), and it is a mixed bag.

> There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me.

Again, I don't know your team, but I would doubt there is no-one on your team you can teach. Pairing is not what I was talking - I personally really dislike it, and it doesn't suit me either. Designing a solution, and helping teammate(s) through implementation of the designs is valuable in this context, and helps lift up other team members.

> If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done.

No one is a perfect engineer - the solution you design might not have been produced, but this team existed before you joined, and most likely will after you leave, and it produced solutions.

> Note that I am relatively new on the team ..

This is a key point - I have done things before that were great solutions / libraries that others could use, so I didn't sink much time into docs / comments in the code. No one would need to change the library, just the config and stuff calling it. Which was true for about 2.5 years, at which point we needed to update what should have been something minor. cue me spending a week trying to understand my own code, after someone else tried and gave up. Time is the real judge of how much impact someone has on a team, and which direction it is in.

Your judgement doesn't really matter in this situation, the distinguished engineer and the rest of our senior team thinks I am doing an awesome job and they review my changelists and design docs. But I realize there is not much I can do to convince you, in your mind I don't exist so you try to find alternate explanations for everything.

> Again, I don't know your team, but I would doubt there is no-one on your team you can teach.

What would I teach them? I can go into an unknown codebase in a new domain and solve problems quicker and cleaner than the team who wrote the code. There is no secret knowledge I posses, no bag of tricks I apply, I just see the code, figure out what happens and solve it. If I could reliably teach that to people then I could become the richest man on earth.

My skills are good enough to reach a decent position as an IC, nothing to brag about really, but they aren't worthless either.

Definitely - I am a internet randomer, nothing I (or others) say should be taken with anything less than a truck full of salt.

I would trust that a DE in GOOG knows how to leverage their team in the most efficient / useful way.

My point isn't that very smart / productive engineers don't exist (they definitely do), but that the meme of the dev in the corner who sits in the dark, and spews out golden code, without talking to anyone else on the team is actively harmful for our industry, especially in the smaller startup R&D teams that the current batch of publicity about them comes from.

It sounds interesting and I wish I could learn something from you. Do you have any idea what are you doing differently? How do you work?

Not the GP but I've been in a similar position:

- Be good (and fast) at Googling things.

- Know your foundations, deeply. Don't memorize design patterns and algorithms: instead, learn how to arrive at them organically and how to analyse and understand them.

- Avoid overengineering like the plague and stop seeking perfection. I've seen lots of teams of "1x" engineers fail because they're too worried about peer approval, so they end up trying too hard to arrive at the "perfect" solution. And then business changes its mind and they have to rearchitect everything.

- Accept that business people will change their minds and design your software around it. The world doesn't revolve around your precious codebase. If the higher ups want to change something, you have to do it. Your codebase should have been malleable enough for a 180 degree pivot.

- Stop chasing unicorns. Yeah, maybe Vim will give you that extra 10% edge you need, but if you're comfortable with Atom, why change?

- Keep it simple, don't be clever. Only use the subset of the programming language that is free of "gotchas". What's the output of `[].push(1)` in ES6? Who gives a shit? Keep that stuff out of your code.

- Learn to evaluate if using an external dependency is actually faster than writing something from scratch or just copying some code. Sometimes it isn't, and people miss out on having simpler code, simpler interfaces AND learning new stuff because of that. Of course, you're not going to do that with a crypto

- Avoid things that might slow you down. The CI taking 30 minutes to run or the compilation taking 10 minutes are a sign that you're doing something very wrong and too complicated.

--

As for practical recommendations:

- A single integration test is better than multiple disconnected unit tests that have the same coverage. It allows you to change your code without changing the tests.

- Avoid transitive dependencies in your classes/functions by using simple Dependency Injection. Just pass those dependencies as a parameter or whatever. This will help you have units of code that are more testable, more flexible and don't require maintenance. Also you don't need those mock-in

- Make code simpler to read and to debug. Avoid reflection, metaprogramming and stuff like that. Don't do things that require magic.

I'm not really sure, but the thing I do most different is that I don't really trust anything. For example, in a mathematics class I wouldn't trust what they taught, instead I always tried to disprove it and I didn't use formulas I couldn't derive myself.

This is a lot of extra work, but it meant that I always had an extremely strong foundation to stand on. When I know something I really know it, and having learned this way since early school I have spent a really long time doing it so it covers quite a lot.

Also when you learn this way you don't forget, so it just compounds. There is no way a person who "cheated" by implementing for example algorithms and data structures without deriving things themselves can compete. They have spent their entire lives learning how to apply things without understanding, they would have to redo all of that to catch up.

When you know things this well then being much faster than others is not very hard. Also creating original solutions is not something scary or time consuming, it is something you've done throughout your entire life.

Anyhow, I am not sure if others can learn this way, I just know it works for me. I've tried teaching others to do it, but it didn't work that well. It might be that it was too late, I just naturally learned mathematics this way from early school so I already knew how to think about algorithms before I even started programming. I mean, calculating things by hand or in your head are the original algorithms so if you can confidently alter those as you wish then you already know the basics of programming.

Reply on news.ycombinator.com