Summary: Never Eat Alone by Keith Ferrazzi with Tahl Raz
chestergrant.com
5 Followers | 21 Following
Follow<3
I learned that real networking was about finding ways to make other people more successful. It was about working hard to give more than you get.
The best thing that can be done to a problem is to solve it. False. The best thing that can be done to a problem is to dissolve it, to redesign the entity that has it or its environment so as to eliminate the problem
We don’t have to monetize or optimize or organize our joy. Hobbies don’t have to be imbued with a purpose beyond our own enjoyment of them. They, alone, can be enough.
Customer interactions drive business value, while the underlying database decisions very rarely do. The modern company seeks to innovate at the top of the stack, close to the customer, not the bottom.
Technical debt is caused by a lack of understanding — it stems from disagreement between business needs and how the software has been written.
In the context of a team the first indicator of too much WIP usually is that everyone in the team is working on something different. For every engineer in the team there is a separate task or even project. Daily stand ups are centered around people not work. There are also very few interactions between people during the stand up, so everyone just pushes their current status to the group.
Sometimes you’ll find work that’s worthy of attention, but which an organization is incapable of paying attention to, usually because its leadership doesn’t value that work. In some companies this is developer tooling work, in others it’s inclusion work, and in most companies it’s glue work.
But regardless of your mission statement, your culture, your values, and so on, if you choose the wrong revenue model, it will dominate them in a shareholder-value-driven, capitalistic society. Culture can only dominate if it’s negative. A positive culture is necessary, but it’s not sufficient.
In other words, over the long term, a company (and its product) will morph to take the shape of its revenue streams.
Meetings are often opinion, rather than evidenced based.
Stop Asking Everyone’s Opinion
The modern organisation is obsessive about collaboration and consultation – but encouraging everyone’s opinions on everything invites bullshit.
In other words, the jobs that seem to best resist technological unemployment are those that involve building, maintaining, promoting, and defending a particular perspective.
Most developers don’t understand open source to be a particular license that certain software artifacts are in compliance with, but an attitude, an ideology. And that ideology isn’t just about the consumption of the software, but also its production. An open source project should have a public bug tracker. There should be a mailing list, for discussion. You should be able to observe, and ideally participate in, the development of the software. Focusing on the code being open is putting the cart before the horse.
In-office and remote work are different platforms of work. And right now, what we’re seeing a lot of companies attempt to port local work methods to working remotely.
The connection to literacy was painfully clear. It isn't enough to just learn to read and write. There is also a literature that renders ideas. Language is used to read and write about them, but at some point the organization of ideas starts to dominate mere language abilities. And it helps greatly to have some powerful ideas under one's belt to better acquire more powerful ideas [Papert 70s]
Once we know the candidate has the required level of competence, most companies focus on what is usually referred to as “cultural fit.”
This is probably one of the most damaging concepts to your efforts to build a great organization.
Of the vast pool of people in the world, companies filter out almost everyone except those that are perceived as a “cultural fit,” which of course is a very ill-defined concept.
For most organizations, “cultural fit” is the politically correct term for what essentially translates into: “hire people that look and think like we do.” In our industry, usually that means white men from top-tier universities with technical degrees, hiring more white men from top-tier universities with technical degrees. In my experience, this is not usually conscious or intentional, but the results are plain to see.
I’d like to try to convince you that “cultural fit” is the wrong objective here.
Even during my hiring period, all my communication was asynchronous.
Of course, you don’t have the freedom to choose to deploy in the cloud just because it makes life easier for you. Some products (operating systems or video game consoles) simply can’t exist entirely in the cloud. If you build for consumers on mobile, you’ll probably choose a native app so you can deliver the best UX, because at least in consumer, rich UX trumps engineering productivity. I know it sounds preposterous, but be prepared for shipping mobile apps to have more in common with shipping operating systems than with shipping for the web. That’s why even if you are mobile first, you want all of the brains of your mobile apps to live on the server where you can easily change them.
As a rule of thumb, expensive software means predictability is key while shipping. Customers need your product. If you have a lower (or no) price tag, focus on UX. Users who don’t need your product have to want it.
La explicación más clara de cómo armar un roadmap usando Mission, Themes, Milestones, Epics y User Stories.
el mejor libro que leí para entender de dónde viene, qué es y a dónde va deep learning
If I don't understand you, it's your fault. This has to be the most basic, fundamental principle of a good software architect (well, of any engineer), but most of the architects I've met so far, in many companies, don't seem to believe in it. They don't understand that the job of a software architect is to make complex things simple, not the other way around
An architect is the one who takes the blame for the quality.
muy bueno para entender events en el marco de event sourcing y micorservices
In this essay, I want to explore what it takes to have a time-series database support the entire enterprise as an operational technology, rather than it being just another information technology, limited to monitoring services in the data center. Why is this important? Just like in the data center, time-series data allow us to make operational decisions in near real-time, rather than having to wait hours or days to make decisions based on traditional batch systems. Time-series data also allow us to look at processes historically, as well as build predictive models for the future. We can prevent problems before they occur, and seize opportunities as they emerge. But perhaps most importantly, in the industrial world, a time-series database tends to become a unifying platform, tying together many disparate systems—sensors, control systems, business systems, legacy systems—into a uniform and democratizing platform for collaboration, analysis, and decision making.