This week featuring marking books, the slowness of big-tech, breaking down tasks and giving feedback to coworkers.
On the Marking of Books
Jacob Allee • Essay • Reading time: 6 min
In this essay, Jacob Allee shares his way on how he marks books during reading. He has an extensive system using different colours and a rule set on when to underline something.
Even though I believe I won’t ever mark up that much as he shared in the photos in his article, I think the essay is worth reading.
My key takeaway: To fully get the content of a book and draw important connections to other documents, I think having a system for marking a book is quite an essential thing to have as a reader.
Why are big tech companies so slow?
Sean Goedecke • Essay • Reading time: 5 min
As a programmer in a big company, I get the underlying thoughts of Sean’s essay. From an outsiders point of view, it seems the development of new features takes ages.
One common statement is this one: “Big tech companies spend a lot of time and money building things that a single, motivated engineer could build in a weekend.”
In the essay, he goes into detail why it takes big companies often much longer to integrate a feature in a already large code base and why startups which focus on a single feature often are much faster in developing.
Some of the quotes which stood out to me:
So why do big tech companies find it so much harder to build? It’s the scale of the app itself: not the number of traffic or users, but the number of features. As that number grows, it becomes more and more difficult to build and ship new features. The reason is straightforwardly mathematical. Each new feature potentially interacts with all the features before it. You have to check to make sure it doesn’t interfere with an existing feature, and if it does, you have make some kind of balancing change to keep both features working.
Startups don’t care about marginal features because their success is entirely dominated by finding a single successful feature that anybody wants to pay for. Big companies by definition have at least one successful feature that’s already driving lots of revenue, so they care a lot about marginal features. 1% of Google Ads or AWS S3 revenue is a lot of money. Big companies are thus incentivized to keep adding complexity until it’s literally impossible to add any more.
My key takeaway: Even though it is fast to judge, there often is a reason for why development takes so long. But this should not be an excuse, one should always search for ways in which a development process can be optimised.
Breaking down tasks – by example
Jacob Kaplan-Moss • Tutorial • Reading time: 10 min
As the heading already states, this tutorial explains how a big project can be broken down into tasks (“a sufficiently defined, complete piece of work that delivers change“) which are small enough to not feel overwhelmed. This process is divided into several iterations.
As the author provides a summary which I could not write any better, I will cite it here:
- Begin where you are: with a list of tasks, a sketch, or even just an idea.
- Think through the steps you’d need to take to accomplish that task, and write them down. Don’t worry about completeness or accuracy or depth, each pass just needs to expand, even slightly, on the previous one.
- For each item on your list, decide if that item is sufficiently defined:
If the answer to any of these questions is “no”, take that task and recurse – breaking it down further using this algorithm again.
- Do I understand what change is desired?
- Do I understand what “done” will look like?
- Can I define all the steps I would take to get to “done”?
- Assuming no blockers or dependencies, do I have all the information I need to start this task right now?
- Repeat until all tasks are sufficiently broken down.
My key takeaway: I think this text is worth reading for everyone. I know the feeling being overwhelmed by the project at hand and not knowing where to start. Using the authors steps, a big project can be split up in many smaller tasks, each of whom can be tackled because it is fully understood.
How To Criticize Coworkers
Alex Turek • Tutorial • Reading time: 14 min
If you ever had to give feedback, you know how tricky it can be. Alex Turek shares important steps on how to give (and receive) good feedback.
… direct feedback to someone is your highest leverage option to get them to be better. It is the least work on your part for the most long-term impact.
Feedback is high leverage because it’s cheap for you to give, and provides high value to the recipient by giving them information early. Their alternative is having to guess at their own performance and behavioral impact.
He defines his principles of good feedback in detailed steps:
- Praise in public, criticize in private.
- Use “I” language instead of “you” language.
- Be as specific as possible using SBI (situation-behavior-impact).
- Be on the same side.
- Stop if you’re too worked up.
- Use a tight feedback loop.
Adding on to this, the post also offers a template on how to give negative feedback:
- Establish context.
- Talk about something they’ve done well.
- SBI: Situation, Behavior.
- SBI: Impact.
- Talk about the trend.
- Let them react.
All of those steps are written out in detail in the post linked above, I highly recommend you to reading it!
My key takeaway: Giving feedback is super important. Having a template in hand for doing so can help massively. I will try to give more and better feedback in the future. If I have to give negative feedback, I will first write it down to make sense of my words before I tell it to somebody.
Hi, my name is Flo 👋
I’m a software engineer from Germany. Thanks for joining me on this week’s episode of Stuff Worth Sharing! I hope you found something intriguing to explore further.
Feel free to share with others who might enjoy these weekly finds.
Until next week,
Flo
P.S. Never miss an issue – subscribe for free to get these curations delivered straight to your inbox.