> And two, we lost a couple of deals last quarter due to engineering challenges I can help solve in weeks but would take my team months on their own. Some of these problems wouldn’t get solved without my help.

Those were not my words. Those were the literal words used by my Engineering manager out of desperation to convey to me that the team needs my help in solving these problems.

I'm not sure why you would take these as "throwing the team under the bus." This is actually expected -- given I wrote a lot of that code, and was the most senior engineer in the whole company.

This was the result of that effort, btw:

https://dgraph.io/blog/post/manual-memory-management-golang-...

And we had the best team we could build with the resources we had access to. 4 of my team members have created 3 companies -- one is YC, one has a wild acquisition offer, and one is Sequoia-backed. And they all seem to like me a lot.

https://twitter.com/poonai_/status/1487090519616356352

As a lurker, I'd suggest you stop talking because you're not helping your case.

As a leader/CEO/CTO, people judge you based on your ability to lead the team, not your personal technical skills. Your posts are throwing away the former in an attempt to demonstrate the latter.

That sentence is being taken out of context. So, I clarified the context.

Moreover, the team in question -- I have spent countless hours working with them -- and they know exactly what I meant. No one ever complained about this blog post or this particular sentence. They knew exactly where I was coming from.

If Glassdoor is a benchmark for the effectiveness of leaders, then might as well vote for whatever Russian trolls tell you to vote for.

People are free to make their own judgments.

It sure seems like you used to work there since you're making specific critiques about company culture and decisions that only someone internal would know.

And you're taking statements like "lost a couple of deals last quarter due to engineering challenges" as being a personal slight against the engineering team when an impassioned observer would not really see it that way.

I don't know the specifics of Dgraph's failings but reading the Glassdoor reviews it sure looks like the main issue is that the CEO failed to organise a bridge round and that the disputes between the CEO and CTO and poor metrics meant the VCs didn't want to provide one.

You can fix any problem at a company except running out of money.

> And you're taking statements like "lost a couple of deals last quarter due to engineering challenges" as being a personal slight against the engineering team when an impassioned observer would not really see it that way.

I have no opinion on this broader company, but you focused on the wrong part of the sentence.

OP was focused on "I can help solve in weeks but would take my team months on their own" -- something that indeed is throwing your engineering team under the bus to me, an impassioned observer.

The CEO's statements come across as insulting to anyone who isn't blinded by founder worship. I'm saying this as someone who did not even know about dgraph before today.

Presuming the GP must be a disgruntled employee because he can read a Glassdoor review is just naive.

Glad you quoted statements from @mrjn / Manish's original post because it looks like he edited a bunch of those out of his post.

And yes it sounds not only like he's throwing his engineering team under the bus but also thinks they were incompetent which is beyond something any C* level person would be silly enough to write.

I read those snippets and thought the same thing. This guy thinks he is god. 1000x engineer.

Deep familiarity with a complex code base is a thing and is not easily replicated. I have seen this first hand. In my day job - I work on a very popular but complex open source project and in my team there is a engineer who has been there since beginning and I am like second person after him.

I have noticed that when we get certain class of bugs from customers(and customers want fix NOW) that spans 2-3 layers of the project, only me and him can pick those bugs. Some decisions are there in the code that is not easy to figure out(like why it was done this way) and I have also seen engineers who are founders of this project - point design issues that I could not have thought (and I am doing this for 5 years!).

Can we hire someone new to provide design reviews that spans network, storage, kernel? May be - but engineers who created this thing and have been doing this for long time, have got really good at it. To me - some of them seem god like. I know they will probably suck same as me, if they had to start developing a new iOS app or write new game for Nintendo Switch.

I have to agree. I worked on a pretty large Java project, we hired 2-3 capable engineers, but they couldn't grasp the complexity of the problem, not necessarily the code - the code was pretty readable if you know what it does and how.

>...only me and him can pick those bugs

Brittle or hard-to-grok code that other engineers avoid is a code smell. Eng leadership/senior engineers ought to prioritize refactoring that code ASAP

There wasn't any implication that the code is "brittle" or hard to grok due to a defect in the software architecture. It may be approximately optimal from the perspective of software maintainability relative to functionality and performance. All code has non-local side effects, but in most software that is buried below the noise floor of inefficiency.

Some types of software are intrinsically difficult to understand e.g. due to highly visible behavioral coupling across multiple unrelated parts of otherwise tidy, modular code. This is a strictly correct and intentional design in many cases but it means even a seemingly small code change can only be evaluated for correctness relative to the detailed internals across diverse code components in various runtime contexts. Reasoning about these systems has a very high cognitive load.

This is one of the reasons writing competent database kernels is so difficult -- the best designs asymptotically converge on being exquisitely complex and subtle monoliths, even when the code appears clean and modular. In my experience, there are always parts of these code bases that only one or two engineers dare modify even though the code is straightforward, because any local change can't be evaluated for correctness without deep expertise in half the system internals.

It really depends on the nature of the software.

> There wasn't any implication that the code is "brittle" or hard to grok due to a defect in the software architecture

Re-reading my comment, it comes off dismissive - I apologies for that. I agree with most of your points

> Some types of software are intrinsically difficult to understand e.g. due to highly visible behavioral coupling across multiple unrelated parts of otherwise tidy, modular code. This is a strictly correct and intentional design in many cases but it means even a seemingly small code change can only be evaluated for correctness relative to the detailed internals across diverse code components in various runtime contexts

Sometimes - the above is the case, but other engineers are unable to maintain those hard parts because the information required to do so is in the heads of the experts (the original author, or the 2nd engineer). In those cases, docs may help, but sometimes the code exhibiting unexpected coupling and/or side-effects may need to be further modularized, OR paradoxically, consolidated and abstracted by an easier-to-keep-in-mind abstraction as the "modularization" is illusive since the seemingly independent modules covertly belong together.

I may be projecting because of my past experiences: at different points I was the only one who could make changes to specific modules, one because it was brittle and had low test coverage (and prone to race conditions), and the other time, it was because there was non-obvious coupling which resulted in high cognitive load as one had to keep several layers of state in mind. On both occasions, refactoring and improving the abstractions would have made it easier for other engineers to safely work on the code.

YMMV if the high-cognitive-load architecture is deliberately chosen - in my case, it was an accident of (commit) history.

Yep this so much. It is not that code is brittle but problem space is hard. What seems like an obvious fix may break other vendors that depend on same behavior etc.

Having said all of that. Modesty is a thing and many engineers wouldn't word things the way Manish worded in aforementioned blog.