241–250 of 269 posts
Avoid all these other types except Solver (we call it Fixer at FB). Anyone who calls themselves these things is weird, and will be hard to rely on. Disregard levels. Disregard titles. Fix what needs to be fixed. Unit tests, CI, docs, there's no such thing as grunt work. Real leadership happens in the IDE and only code matters - everything else is overhead.
Earlier quoted context omitted.
> Many people have been skeptical of the idea of the 10X engineer. Why is 10x anything such a skeptical concept? We see it everywhere. We see it in quality, impact, and effort. Linus wrote git in days, and it was way better SVN. Messi is probably 100x better in terms of stats and skills and 100000x better in terms of earning when comparing to an average soccer player Apple's iPod is 10x better than Zune and makes 100…
> Linus wrote git in days, and it was way better SVN. Linus designed and coded some data structures, and some basic utilities to manipulate and store them, in just a few days - based on a fundamentally better model and as a replacement for an existing product they could no longer use. Designing and developing git into a usable product and system took a whole lot longer and involved thousands of people. The examples y…
I urge you to reconsider not being pedantic next time
And what Linus initially wrote was definitely a usable product. The product has evolved more since then, but that doesn't mean the initial version doesn't work. Actually most of the original code still exists.
Back to the original point, this is the example of a >10x engineer (by impact, coding speed, innovation) who conceived, wrote a popular software in days, grew the community, and grew it to the insane popularity today. Only a handful of engineers in the world could ever achieve this kind of things.
Earlier quoted context omitted.
Do you really think it’s because of the software or because of the product? I bet no one has said that if only Twitters software was better it would gain more customers and advertisers. All indications are that Twitters architecture is now top notch. There are entire sections of “Designing Data Intensive Applications” (the Bible for system design interviews) about Twitters current architecture.
I think as systems get more complex and bogged down, it's harder to innovate. As innovation is stifled by build problems, dependency problems, political problems, operational problems, the amount of code you have to read to do anything problems, etc, I think engineers start to say "could I be more productive, and therefore theoretically get more reward, elsewhere?" I think as soon as the innovators start to jump ship…
I seriously doubt Twitter is one large monolithic app
And let’s not pretend that Google for instance is any better at product development. It’s failed at everything it’s done not related to advertising - ie Stadia. It’s one success hides a lot of failures.
Earlier quoted context omitted.
Thanks for explaining! The last time I was involved with job-title hierarchies (a long time ago), nobody was a programmer, everyone was an analyst. The people who did telephone support were called support analysts. I graduated to senior sales support analyst (roughly, doing random free work for the prospect, to close a sale). We assumed we were superior to "engineers": they were the guys that swapped-out hard disks a…
It is kind of the opposite now, at least in the US/SV. Programmers are “Software Engineers” and many programming-adjacent roles like support are given titles like “Product Support Engineer” Personally I think Software Engineer is a better descriptor of what we do than Programmer/Analyst, though of course not everybody with the title is actually engineering systems.
I call myself a programmer, or sometimes a "software developer". But even the latter term is fishy, to me; it has connotations of "research and development", as if there's something blue-sky and innovative about building a commercial website.
Incidentally, my dad counselled me to NOT go into programming as a trade[0]. I ignored his advice, and I did OK.
[0] Yes, I consider myself a tradesman, not a "professional". Professions are trades that are policed by a professional body; there are professional bodies for programmers, but hardly any programmers belong to those bodies, and if you list your membership on your CV, it'll probably reduce your chance of getting an interview.
Earlier quoted context omitted.
Thanks for explaining! The last time I was involved with job-title hierarchies (a long time ago), nobody was a programmer, everyone was an analyst. The people who did telephone support were called support analysts. I graduated to senior sales support analyst (roughly, doing random free work for the prospect, to close a sale). We assumed we were superior to "engineers": they were the guys that swapped-out hard disks a…
> I guess maybe the difference might have been that we (analysts) had degrees, and they didn't Interesting nomenclature given that in many countries you can't even call yourself an engineer without an accredited degree and being licensed by the proper regulator.
> Right Hands often dive into a fire, edit the approach, and delegate execution to the most appropriate team, and then pop over to the next fire elsewhere in the organization. > The Solver and Right Hand bounce from fire to fire, often having more transactional interactions with the folks they’re working with on any given week. It's worth noting that Ben Purgason from LinkedIn, identified Firefighters as stage 1 and…
"Firefighting" is being used in two different contexts here. In the SRE document, it means literal incident response, while in the Staff Eng context, it means "addressing whatever the organizational P0 is", which may occasionally be a literal incident, but it may also be developing an incident response team, or lending a hand to a project that is behind schedule, or...whatever. There's always something that is highes…
Good point. That's right.
> There's always something that is highest priority, and having a floating person(s) who can continually identify and provide support for whatever that thing is isn't a sign of a dysfunctional organization.
Yes, I do think that "floating" is an appropriate term here. I've also seen "consulting engineer" used in this context within large multinational organizations.
However, I would point out that too much floating may be a sign of diminishing returns on matrix management.
Earlier quoted context omitted.
This reminds me of an old essay: https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n... The thesis is that the "10x engineers" don't output a linear multiple of the same kind of work their peers do. Instead, they implement solutions that their peers wouldn't or couldn't over any length of time. This matches my experience.
The 10x engineer identifies common subproblems across different problems, and then creates a layer of reusable code which becomes a library. Then uses this library to write code 10x faster. The 10x engineer tries to standardize problems and solve them en-masse. The 1x engineer sees every problem as a different problem that requires a different solution. The 10x engineer talks about abstractions, the 1x engineer talks…
Now, as a leader type, I would prefer to hire 1x engineers to 10x engineers, for a whole litany of reasons. 1x engineers are largely predictable, where as 10x can be 10x in any wild direction, because they're more or less deciding for themselves a bunch of shit they really shouldn't be.
10x engineers like to decide for themselves things like how to go to market or which features to build in what order, without doing any of the requisite research or information gathering necessary. It's infuriating because 10x engineers think passion or some arbitrary definition of "Correctness" gives them power, when in reality they're just operating with a heavily limited set of information (gee, I wonder how they had all that time to build stuff, maybe because they weren't attending meetings???).
Sorry, this turned into a not-very-coherent rant, but the point is 10x engineers aren't worth hiring as anything other than literally employee #1, and even then it's a huge dice roll.
Earlier quoted context omitted.
im actually amazed you never ran into politics at work. you never needed to navigate around egos to get what you want, you do every thing purely on merit, every decision is only technical? my whole career as been filled with stuff like people forcing their pet projects on the company, people hiring their friends and dealing with their in crowd
> you do every thing purely on merit, every decision is only technical? Yeah, honestly. The vast majority of my hard decisions I made were based on schedule and resources: having to kill things or move people around. The only "political" anomaly I witnessed was that it seemed the employees at the Israel Design Center at Intel were getting promoted to principal at a much faster rate, and with much less years and exper…
This is jaded and angry, but I think there is another archetype called "the politician." They play the game extremely well, providing poorly thought out solutions quickly to problems they haven't dug into the complexity of. They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Once they've picked the low hanging fr…
> They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Specific to your example, rather than the sentiment, I think embedding config in code is highly valuable when you don't have a lengthy deployment cycle and have direct access to the source. It gives your compiler more information which can help prevent bad con…
Config will always move towards code as systems become more complex and scale up. At some point code-config will have an output intermediary data structure that is consumed by what consumes configs. I don't really have a problem with that.
I am talking about things like querying a database and inserting what would otherwise be a row in the database in the code that does the query itself. So if you need to do debugging, you go do a query against your database and the row isn't there. It sounds absurd, but I have seen it, and caused an outage because of it.
Earlier quoted context omitted.
I agree, configs in code are not a bad thing necessarily if they don't change often or at all. Sprawling config files are a significantly higher challenge to get your bearing with.
I’ve been trying unsuccessfully to get buy in on config as code. Instead we have property / yaml files, read into anaemic “classes” which do not perform validation themselves. Validation duties are also foisted onto other parts of the system. Stacked onto that we sometimes have file name based convention for defining a hierarchy of configs, to save on repetition between environments.
I would make sure when implementing it you have someone who is very opinionated review all configs to ensure that the same behavior is always implemented in the same way until a linter can enforce idioms. I would avoid explicit conditionals and explicit loops, instead relying on implied conditionals and implied loops. I would absolutely not use any "live" data, meaning the code should be relatively pure without any dependencies.
Pystachio is not a bad choice in python land: