These themes resonate a lot with my article of "Making the Most out of your Software Engineering Internship" and "Things I wish knew before starting out as a software engineer" articles in Karthik's Newsletter (karthiksubramanian.substack.com)
Great title, you got my attention on how to become top 1%, haha. One thing I definitely related to was owning the meeting when there’s no moderator. It’s a great way to demonstrate leadership capabilities!
It's insightful when you realize that the impact you can have on making a 10-people meeting more efficient is huge. You are scaling your impact to 10 people and most meeting are recurrent, so you are scaling over time the effects
Such an wesome article. I have already doing things like making document if needed. Write test cases of untested code/features. After your article, I deciced to make meeting notes, doing refactoring volunterrly.
For work I can't use tools that have cloud sync and my company doesn't have a partnership with (e.g. Notion 😔)
So I pay more attention to the system than the tool. I use Obsidian and my process is the following
- Capture almost raw notes of the conversation. At first I was capturing every word, now I'm more comfortable capturing the topics talked about
- Highlight anything that is an important topic or action item
- After the meeting go through those highlights and
If I need to revisit the full notes, I can go back, but that's like 1 out of 10 meetings. Most of them with capturing the action items and most important things I have enough. If I have to send meeting notes, I send them immediately after and those meeting notes become the source of truth of the action items agreed with the attendees.
Then those Action Items I put them into my to-do-list to ensure they aren't lost in the pile of meeting notes
Things like meeting notes are not only useful for others, but they are a way to protect yourself. Once a decision is made, sending the meeting notes gives you an artifact to justify the decision if somebody questions it later.
I started using them when I was running in circles of decisions that were challenged a few weeks later
Great article, Fran. I like the meetings section. I think it's super important to take actions in meetings, and simply do something, instead of just being a listener. You gain more credibility when you are proactive in meetings.
Yeah, I think my brains feel too bored if I'm just listening and defaults to multi-tasking on something else. Better to "multi-task" by taking notes of the meeting itself!
Thanks for the shoutout, Fran 😊 The best thing about these tips is that you can apply some of them from day 1.
> Refactor, add tests to untested functionality and contribute to the readme.
This is a 1% hack I've been doing since forever when I join a new project.
While I avoid refactoring when new, writing tests helps you understand the codebase better and how components are related. And because you have to follow the readme to set up the software, you'll likely encounter outdated steps you can update!
Keeping the discussion going in GitHub PR comments is also vital because it encourages you to land a better solution than either of you (the author and the reviewer) initially thought of!
Amazing article! Very crisp and to the point.
These themes resonate a lot with my article of "Making the Most out of your Software Engineering Internship" and "Things I wish knew before starting out as a software engineer" articles in Karthik's Newsletter (karthiksubramanian.substack.com)
Great title, you got my attention on how to become top 1%, haha. One thing I definitely related to was owning the meeting when there’s no moderator. It’s a great way to demonstrate leadership capabilities!
Thanks, Akash!
It's insightful when you realize that the impact you can have on making a 10-people meeting more efficient is huge. You are scaling your impact to 10 people and most meeting are recurrent, so you are scaling over time the effects
Such an wesome article. I have already doing things like making document if needed. Write test cases of untested code/features. After your article, I deciced to make meeting notes, doing refactoring volunterrly.
Do you use a tool for making meeting notes?
Hey Sabih,
For work I can't use tools that have cloud sync and my company doesn't have a partnership with (e.g. Notion 😔)
So I pay more attention to the system than the tool. I use Obsidian and my process is the following
- Capture almost raw notes of the conversation. At first I was capturing every word, now I'm more comfortable capturing the topics talked about
- Highlight anything that is an important topic or action item
- After the meeting go through those highlights and
If I need to revisit the full notes, I can go back, but that's like 1 out of 10 meetings. Most of them with capturing the action items and most important things I have enough. If I have to send meeting notes, I send them immediately after and those meeting notes become the source of truth of the action items agreed with the attendees.
Then those Action Items I put them into my to-do-list to ensure they aren't lost in the pile of meeting notes
I hope anything of my process is valuable! :)
I'm glad it inspired you, Abdul!
Let me know how it goes :)
Things like meeting notes are not only useful for others, but they are a way to protect yourself. Once a decision is made, sending the meeting notes gives you an artifact to justify the decision if somebody questions it later.
I started using them when I was running in circles of decisions that were challenged a few weeks later
Lot of great strategies here!!
Thanks, Nishaz!
Great article, Fran. I like the meetings section. I think it's super important to take actions in meetings, and simply do something, instead of just being a listener. You gain more credibility when you are proactive in meetings.
Yeah, I think my brains feel too bored if I'm just listening and defaults to multi-tasking on something else. Better to "multi-task" by taking notes of the meeting itself!
Thanks for the shoutout, Fran 😊 The best thing about these tips is that you can apply some of them from day 1.
> Refactor, add tests to untested functionality and contribute to the readme.
This is a 1% hack I've been doing since forever when I join a new project.
While I avoid refactoring when new, writing tests helps you understand the codebase better and how components are related. And because you have to follow the readme to set up the software, you'll likely encounter outdated steps you can update!
Keeping the discussion going in GitHub PR comments is also vital because it encourages you to land a better solution than either of you (the author and the reviewer) initially thought of!
Thanks Akos!
Yeah, all the mindset of the post is doing simple things that drive an impact.
We can also be outliers doing super complex things, but I haven't found yet a recipe for that :)