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

91–100 of 112 posts

Re: Things I learned from building a production database

#91

Post by jkob_ »

polskibus wrote: post #81
ketzo wrote: post #70

Earlier quoted context omitted.

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.

More of a team leader at least, non-IC. Some Senior ICs deliberately don't want any part in politics, just want a task and want to get it done (see for example advice on HN about avoiding meetings and politics at all costs).

Sorry, but what does IC mean?

Re: Things I learned from building a production database

#92

Post by lumos_42 »

jkob_ wrote: post #91
polskibus wrote: post #81

Earlier quoted context omitted.

More of a team leader at least, non-IC. Some Senior ICs deliberately don't want any part in politics, just want a task and want to get it done (see for example advice on HN about avoiding meetings and politics at all costs).

Sorry, but what does IC mean?

Individual contributor

Re: Things I learned from building a production database

#93

Post by mellavora »

jkob_ wrote: post #91
polskibus wrote: post #81

Earlier quoted context omitted.

More of a team leader at least, non-IC. Some Senior ICs deliberately don't want any part in politics, just want a task and want to get it done (see for example advice on HN about avoiding meetings and politics at all costs).

Sorry, but what does IC mean?

some people would say "Independent Contributor", which appears to be a level in some large corporations.

Re: Things I learned from building a production database

#94

Post by khamba »

jkob_ wrote: post #91
polskibus wrote: post #81

Earlier quoted context omitted.

More of a team leader at least, non-IC. Some Senior ICs deliberately don't want any part in politics, just want a task and want to get it done (see for example advice on HN about avoiding meetings and politics at all costs).

Sorry, but what does IC mean?

Individual Contributor. ICs are not managers, or Team Leads, or any of people leading positions.

Re: Things I learned from building a production database

#95

Post by [deleted] »

jkob_ wrote: post #91
polskibus wrote: post #81

Earlier quoted context omitted.

More of a team leader at least, non-IC. Some Senior ICs deliberately don't want any part in politics, just want a task and want to get it done (see for example advice on HN about avoiding meetings and politics at all costs).

Sorry, but what does IC mean?

[deleted]

Re: Things I learned from building a production database

#96

Post by epr »

lysecret wrote: post #89

The main thing i learned in my first production db work is that you pay for every bit of complexity you introduce. As a noob you are somehow much more afraid to not "model the data right" so you tend to create much to many tables much to many n to m relationships you make everything a string a uuid a relationship, never use bools etc. But then you have to iterate and live with those systems and then you pay and every…

> 1. We don't want to delete old data so we just use a "deleted" column and do that instead. Now every single time you have to filter out those results. 2. You just made this thing a relationship now every time you have to join.

Whether or not these were good decisions depends on the use cases of course, but papering over db implementation details like this with a view is pretty straightforward, no?

Re: Things I learned from building a production database

#97

Post by bob1029 »

lysecret wrote: post #89

The main thing i learned in my first production db work is that you pay for every bit of complexity you introduce. As a noob you are somehow much more afraid to not "model the data right" so you tend to create much to many tables much to many n to m relationships you make everything a string a uuid a relationship, never use bools etc. But then you have to iterate and live with those systems and then you pay and every…

This is the whole point of the database: model the data exactly the way the business needs it, so you can have easy 1:1 conversations. Then, build some convenience views or other mapping layers on top of this data for use in reporting systems, etc.

Don't screw up the physical tables just because you don't like the knowledge that they contain in certain contexts. Facts are facts. If you don't like what you are seeing, change your query or filter the result set. If a customer record needs to be retained after deletion per biz requirements, then an IsDeleted fact is 100% the right path.

Both of your points enumerated above are trivially solved with views.

Re: Things I learned from building a production database

#98

Post by dgb23 »

maheshba wrote: post #26
turbocon wrote: post #5

I really think this is a great list however I think one of the major factors why this project succeeded isn't listed but is mentioned in the intro. > We hit production with a 3-person team in less than a year; and subsequently scaled the team to 30+ engineers spanning multiple sub-teams Starting with a small skilled team to build the core and actively plan for a larger team at some point is absolutely critical for pr…

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…

Reminds me of Kent Beck's 3x [0] (there are also video presentations online).

So from that perspective you're describing the first two "explore" and "expand". The third is also interesting "extract" where a project reduces risk over everything else.

Both are missing the fourth part of a lifecycle. If we take the 4x analogy further (which is a popular video game genre) then there would be a "extinguish" phase. In a 4x video game that is where you take over the whole play area (map etc.), essentially by bullying out or assimilating the other factions.

In the real world this is also kind of true (see Amazon as a popular example in tech, or price dumping strategies practiced by Pharma and other large industries). But it is generally frowned upon as it hurts the economy and erodes social contracts. Also for most projects and organizations it isn't feasible to do so. So the "extinguish" part could be understood as "gracefully fading out" from which new cycles can be grown.

[0] https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-ex...

Re: Things I learned from building a production database

#99

Post by polskibus »

jkob_ wrote: post #91
polskibus wrote: post #81

Earlier quoted context omitted.

More of a team leader at least, non-IC. Some Senior ICs deliberately don't want any part in politics, just want a task and want to get it done (see for example advice on HN about avoiding meetings and politics at all costs).

Sorry, but what does IC mean?

A friend described it to me once "a leaf node" in entire company structure - not a manager. I think it is a good description, also reason why saying "engineer" does not cover all ICs.
Post reply on HN