justjico

I would also recommend Value Based Strategy by felix oberholzer gee. Here’s a link to a video he made summarizing top ideas in the book: https://youtu.be/o7Ik1OB4TaE

Well, isn’t this just the old paradox of free will.

You are free to do whatever you desire. But you are not free to choose your desires.

How would you feel if they offered compensation, say for your 30 hrs?

Agreed. But the problem itself may not really be an engineering problem, and therefore a potential solution may exist outside.

I agree though, particularly in tech, the tendency is for great leaders to be deeply knowledgeable on engineering details because that is a requirement for a good strategy.

Nonetheless, in a broader sense, defining success for a business can create a solution space that extends well beyond engineering.

For anyone interested in learning more about strategy, I highly recommend Richard Rumelt’s book “Good strategy, bad strategy”. This link provides a good summary of the book: https://www.mckinsey.com/business-functions/strategy-and-cor...

I often see the word “Strategy” thrown around, often referring to meaningless corporate speak or fluff. In fact, it’s a whole field of study, and I feel many engineers will love it if they gave it a chance.

In order to develop a strategy you must have a challenge or hard problem to solve. Then you define a cohesive set of actions or policies backed by an argument to solve the challenge. Strategy should define the “how” to solve the problem by clearly articulating the hard choices you have to make.

“Increase customer value”, or revenue or profits, those are not strategies. Being the best, or “leading”. Those are goals or wishes. Defining how to achieve that, given a whole set of constraints, that’s the heart of strategy. And engineers are generally great at solving those type of complex puzzles.

The solution is not one that may involve code or even engineering in general, but rather, a clear understanding of the problem, its constraints, and the argument for choosing some specific set of trade-offs.

Ironically I read it as part of my eMBA.

Just from the docs, it appears to rely on the warehouse itself. It’s basically SQL + js templates make data engineers/analysts jobs easier.

I agree. Even if within the same building, I find it more ergonomic to screen share / voice chat than awkwardly try to share the same monitor, etc.

I believe this is where CQRS plays nice with “event sourcing”. You write all your events in one model, but can read them in multiple ones, that is if you can tolerate some read latency... and most systems are usually ok with that.

Tons of good advice on this previous post: https://news.ycombinator.com/item?id=17654487

100% Agree. It’s like saying Coca-Cola is not a marketing company, they sell beverages. Or Apple is not a “design” company, they sell hardware. sigh

As adviced somewhere else, before you have a DBA, you should consider buying a hosted service like RDs, that would provide at a minimum backup's and restore points. Even have separate dev and prod accounts on RDS.