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

Things I learned from building a production database

maheshba.bitbucket.io

Post reply on HN
Print view View original

61–70 of 112 posts

Re: Things I learned from building a production database

#61

Post by haimez »

xyzzyz wrote: post #44
jiggawatts wrote: post #38

Earlier quoted context omitted.

I wonder if it says anything about Facebook's culture that I've never heard of the term Individual Contributor before. Everywhere else, it's Team Member or something along those lines indicating that you're not on your own.

“IC” is also commonly used at Google and at many other companies. It is by no means a Facebook thing.

I would add that, in context- it’s commonly used to differentiate job functions between managers and… well, ICs at companies where managers and ICs are peers or where ICs are potentially more senior than some managers in title and pay, sometimes by a lot.

So yeah, it’s a term of industry that often shows up in tech companies because of the usefulness of that distinction in those environments.

Re: Things I learned from building a production database

#62

Post by vishnugupta »

Lot of good, actionable learnings there. I liked this one in particular.

> [26] In a transparent codebase with quick review cycles, APIs will leak implementation details unless you gate-keep.

It's tempting to make quick fixes to APIs but please take it slow. Think through existing customers as well as how could new ones will use it.

Also, something I learned while building/maintaining public APIs was to always clearly document (along with examples) the context in which an API should (ideally) be used and how it combines with other APIs to enable common use cases.

Re: Things I learned from building a production database

#63

Post by BatteryMountain »

aurelius83 wrote: post #56
maheshba wrote: post #26

Earlier quoted context omitted.

That's a great point; I should definitely have included it in the list! I think new projects (especially ones that seek to innovate) have two phases: in the first phase, everyone's trying to kill it; in the second phase, everyone's trying to grow it. The kill-it phase is actually valuable for exactly the reason you outlined: it gives a small team the chance to create something highly coherent. (The grow-it phase is s…

Can you explain more what you mean by the kill-it phase? Why is everyone trying to kill it?

Have you tried to build something (lets say, a new kind of storage engine that is not SQL-based) and bring it up to other developers or people at your workplace (never mind business guys)? What is/was their response? Perhaps kill it with fire. If not due to valid technical reasons, financial reasons might seal the deal for it.

And I totally understand the impulse to kill it. Do not unleash it onto the world unless you have thought about your projects long term future (something php & js ignored to do at the time it seems). Thus you end up with tons of pet projects that are either sensibly kept private/ununleashed or because people fear the judgement of others (aka the kill it impulse).

I'd say the nature of the beast is that entrenchment/reinforcement of existing tools/patterns and mental models tend to stick around as they are safe, so a ton of innovation never occurs as someone might not bother to follow a certain path. It's the same with water flowing into existing grooves/cracks in rocks, instead of making new grooves, unless forced to.

Re: Things I learned from building a production database

#65

Post by vishnugupta »

aurelius83 wrote: post #56
maheshba wrote: post #26

Earlier quoted context omitted.

That's a great point; I should definitely have included it in the list! I think new projects (especially ones that seek to innovate) have two phases: in the first phase, everyone's trying to kill it; in the second phase, everyone's trying to grow it. The kill-it phase is actually valuable for exactly the reason you outlined: it gives a small team the chance to create something highly coherent. (The grow-it phase is s…

Can you explain more what you mean by the kill-it phase? Why is everyone trying to kill it?

I have been part of platform and product teams. So I think I sort of know what the author means by "kill-it" phase.

When new platform is being worked upon it's extremely difficult to get product teams to adopt. The PMs on the product teams view a new platform as a distraction because it seemingly doesn't help them launch new features. Worse it's taking the engineers who could be working on features to integrate with this new platform.

Typically during planning phase not too many oppose a new platform. However, when it comes to integrating (or adopting it) then everyone suddenly becomes conservative; no one wants to be the first mover, take the risk to be early adopter. It could also stem from product teams' prior experience of having burnt their fingers trying to integrate with a new platform.

I have seen quite a few platform teams get abandoned after everyone signed up. The platform team need to put in an extra effort to get product teams adopt.

Re: Things I learned from building a production database

#66

Post by mst »

xyzzyz wrote: post #43
andrewmunsell wrote: post #40

Earlier quoted context omitted.

Isn't diff just a standard, generic term for a change difference? (Like in git: https://git-scm.com/docs/git-diff ) Someone correct me if I'm wrong, but if my memory is correct, I was under the impression that a pull request was a term coined in the early Github days specific to their PR feature.

Yes, diff is a generic name, after a Unix tool with the same name. However, it hadn’t been the most popular name for the self contained unit of changes, that you would send to others to review or apply — the “patch” was. In Linux git workflow, you would use the “git format-patch” command to generate patch to send to others for review and to apply it to their branch.

However, even if you're using an email based workflow you're still making a request to somebody to pull your changes into their tree, and I'm reasonably sure 'pull request' as a term for that came from the linux workflow. GH more provided features to formalise a common concept (which, even where I've disagreed with them on the details of how they formalised it, has definitely been a net win overall).

Re: Things I learned from building a production database

#67

Post by hboon »

jiggawatts wrote: post #38
maheshba wrote: post #20

Earlier quoted context omitted.

author of the post here: apologies for the acronyms! I code-switched from academia/research to industry via FB a few years back and just picked up a bunch of terms that I thought were universal in industry. IC does mean Individual Contributor or "person that is not a manager" -- I'll add a definition on top!

I wonder if it says anything about Facebook's culture that I've never heard of the term Individual Contributor before. Everywhere else, it's Team Member or something along those lines indicating that you're not on your own.

> Everywhere else, it's Team Member or something along those lines indicating that you're not on your own.

Individual Contributor means you don't manage other people, but it doesn't imply you are a team member. It helps to think of it as a role where at some point one is senior/skilled/specialized enough to contribute as a team of 1, working with one or more teams at a time.

Re: Things I learned from building a production database

#68

Post by mst »

ajcp wrote: post #11
tyingq wrote: post #7

There was a comment asking what an "IC" was, but the comment was flagged and now dead. Guessing by the context, I'm pretty sure it means "individual contributor", or "person that is not a manager".

"Interface directly with customer ICs" I've only ever seen it to mean "individual contributor", but then this would make it odd/bad advice. There should only be 1 "customer". Sure, that customer may have a whole team that actually needs the product, and may provide them for clarification or what not, but to avoid unrecorded/incorrect handshake agreements, specs, or pet requirements that have nothing to do with the in…

When multiple teams are using the thing, talking to at least one developer on each of those teams is going to surface things you won't find out anywhere else.

I agree that an individual user shouldn't be driving roadmap stuff directly, but getting their perspective, pet peeves, war stories etc. is still valuable advisory input to the overall process.

Re: Things I learned from building a production database

#69

Post by mst »

notacoward wrote: post #24
Avalaxy wrote: post #17

Earlier quoted context omitted.

> IC is a commonly used acronym for Individual Contributor Its not though. Outside of hacker news I have literally never heard this term before, nor does it make any sense. If I'd start talking about "Individual Contributors" to my colleagues they would all be confused wth I'm talking about and wondering what's wrong with me. Who even coined this stupid term, and why do we pretend we need a new name for "engineers"?

It has been around in industry for at least twenty years. Facebook is a bit unusual in using it as an actual job title, but it's by no means new. I remember talking about how DEC had a healthy IC track separate from going into management, and DEC hasn't even existed as a separate company since 1998.

It's certainly regularly used but of course 'regularly' and 'common enough you can assume your audience already knows it' aren't necessarily the same thing in practice, usually at the most inconvenient possible moment.

Re: Things I learned from building a production database

#70

Post by ketzo »

physicles wrote: post #52

> [10] Make your project robust to re-orgs. A company management hierarchy is inherently fragile (a tree is a 1-connected graph, after all); socialize the project continuously with managers who might take over in the future. Do whatever it takes to make sure that manager churn does not result in unfair career outcomes for ICs. > [17] For storage systems, bias heavily in the beginning towards consistency and durabilit…

This is, to me, the definition of a senior software engineer. Awareness across every single part of the process of making software. Not expertise, necessarily, but enough knowledge to know what to be on the lookout for.
Post reply on HN