Emma Goto
A very thoroughly-researched fiction book about the haenyeo women on Korea's Jeju island. I only really knew of Jeju as a popular vacation spot for Koreans (and foreign tourists too), but there's a lot of history there to unpack. From Japan's colonisation, the US taking over after WW2, to the horrific massacres that decimated the population - there's some heartwarming bits but it's not a fun book.
Also just learning about the haenyeo in general, who dived up to 20m to harvest abalone, octopus etc. and uniquely it was the women who brought home the money and the men that stayed home with the kids. (Although somehow it still seemed like the men had some of the power. Funny how that happens).
Originally posted at www.emgoto.com.
A very thoroughly-researched fiction book about the haenyeo women on Korea's Jeju island. I only really knew of Jeju as a popular vacation spot for Koreans (and foreign tourists too), but there's a lot of history there to unpack. From Japan's colonisation, the US taking over after WW2, to the horrific massacres that decimated the population - there's some heartwarming bits but it's not a fun book.
Also just learning about the haenyeo in general, who dived up to 20m to harvest abalone, octopus etc. and uniquely it was the women who brought home the money and the men that stayed home with the kids. (Although somehow it still seemed like the men had some of the power. Funny how that happens).
Originally posted at www.emgoto.com.
The main character, Elena, who is now in her 60s, recounts a childhood spent growing up with her best friend Lina in Italy. The pair are both from poor(er) families, but do well in school. They end up leading diverging lives as their individual circumstances change. The story and characters are vividly written and I read the entire book in one sitting.
There's a 1 chapter setup for the book in present time, before a 50 year jump back in time for the rest of the book. The story ends on an abrupt cliffhanger. At first I thought this was some sort of literary technique to make you go and reread the first chapter to piece together what happens, but no this is actually just the setup for the next book (lol).
I mean I miiiight go read the second, and I am sort of curious about the HBO series although unfortunately I'm not sure where to view it in my country!
Originally posted at www.emgoto.com.
The main character, Elena, who is now in her 60s, recounts a childhood spent growing up with her best friend Lina in Italy. The pair are both from poor(er) families, but do well in school. They end up leading diverging lives as their individual circumstances change. The story and characters are vividly written and I read the entire book in one sitting.
There's a 1 chapter setup for the book in present time, before a 50 year jump back in time for the rest of the book. The story ends on an abrupt cliffhanger. At first I thought this was some sort of literary technique to make you go and reread the first chapter to piece together what happens, but no this is actually just the setup for the next book (lol).
I mean I miiiight go read the second, and I am sort of curious about the HBO series although unfortunately I'm not sure where to view it in my country!
Originally posted at www.emgoto.com.
Last month I finished reading The Pragmatic Programmer. I will admit I don’t necessarily *enjoy* reading software development books in my spare time, but I definitely got some good insights out of this book that I want to apply going forward.
Build a knowledge portfolio
Your knowledge portfolio is all the facts, experience and knowledge that you have related to programming. Similar to how you’d build a financial portfolio, you should make sure that your knowledge portfolio is diversified - you don’t want to put all your eggs in one basket! Keep an eye on technology trends, and make sure to “invest” in new areas or new technologies. Learn a new language once in a while.
If you want to “buy low and sell high”, you could learn an emerging technology before it takes off, which can lead to a large payoff (if it does take off!). The authors suggest also reading technical books, taking classes in a new area you’re interested in, or joining meetups.
I know for me personally right now I’ve been very focused on React due to my job, but I do want to branch out into checking out other frontend frameworks and technologies like Svelte, Preact or Vue. I’ve also got my eye on learning a bit of Ruby on Rails so I can try and contribute to the DEV repository.
Make sure your code is orthogonal
In software, two things are considered orthogonal if a change in one does not affect the other. For example, if you had an app with a database and a UI, swapping out the database shouldn’t require you to touch the UI.
Ask yourself: If I dramatically change the requirements behind a particular function, how many modules are affected?
As a general rule, you want your components to be self-contained. This reduces risk - if you’re relying on a third-party library, but want to swap it out for another one, this should become relatively straightforward. If you make changes in an area, you will feel confident that these changes won’t affect anywhere else. Having simpler, smaller components will also mean it’s easier to write and run tests on them, as well as making things more reusable.
Achieve editor fluency
Being fluent with an editor basically involves knowing a lot of shortcuts. When you’re writing code, you want to spend less time thinking about *how* to write the code into your editor and more time spent being in the flow of writing the code. I know how to comment and un-comment a line, but I have no clue how to select a select a word at a time or line at a time (I just use my mouse to select things) so I know this is something I need to work on.
If you want a challenge, you could stop using your mouse or trackpad for a week, and only use the keyboard to code. The less painful way to achieve editor fluency is to ask yourself, as you code, if there’s a simpler way of doing the thing you’re doing. Then go and find that out, and start using it whenever you can. This may be a new keyboard shortcut, or it may be a new extension you can install on your IDE. If you can’t find a solution, you could even write your own extension.
Have an engineering daybook
The authors recommend carrying around a paper notebook, and using it to take notes every day with what you’ve been working on. It can also be a place where you store ideas. The benefit here is that you can look back on it later, and re-remember why you decided to do something the way you did. The act of writing a problem or solution down can also help you take a step back and realise if you’re doing something wrong.
The book specifically recommends using paper and not a digital solution - which is not something I’m sure I agree with. I do currently take some notes on my laptop when I’m stuck with something and find the solution later, which has been useful as ideas for blog posts, and I definitely want to keep this habit up. I might extend it to writing more of a daily log of what I’ve been working on.
Use property-based testing
When you write unit tests, you generally think about the ways your code could go wrong, and write tests to cover those cases. But what happens if you make an incorrect assumption while writing these tests, or don’t realise you’ve missed a specific edge case?
Enter property-based testing. Instead of providing one input and testing for one specific output, you’d provide a property (for example, when testing a sorting function the property would be asserting that the result is properly sorted) and then the test would test a bunch of different, random combinations to try and see if the property ever fails. Depending on the language you use, there will be probably be a property-testing library out there, e.g. JSVerify for JavaScript.
Originally posted at www.emgoto.com.
Last month I finished reading The Pragmatic Programmer. I will admit I don’t necessarily *enjoy* reading software development books in my spare time, but I definitely got some good insights out of this book that I want to apply going forward.
Build a knowledge portfolio
Your knowledge portfolio is all the facts, experience and knowledge that you have related to programming. Similar to how you’d build a financial portfolio, you should make sure that your knowledge portfolio is diversified - you don’t want to put all your eggs in one basket! Keep an eye on technology trends, and make sure to “invest” in new areas or new technologies. Learn a new language once in a while.
If you want to “buy low and sell high”, you could learn an emerging technology before it takes off, which can lead to a large payoff (if it does take off!). The authors suggest also reading technical books, taking classes in a new area you’re interested in, or joining meetups.
I know for me personally right now I’ve been very focused on React due to my job, but I do want to branch out into checking out other frontend frameworks and technologies like Svelte, Preact or Vue. I’ve also got my eye on learning a bit of Ruby on Rails so I can try and contribute to the DEV repository.
Make sure your code is orthogonal
In software, two things are considered orthogonal if a change in one does not affect the other. For example, if you had an app with a database and a UI, swapping out the database shouldn’t require you to touch the UI.
Ask yourself: If I dramatically change the requirements behind a particular function, how many modules are affected?
As a general rule, you want your components to be self-contained. This reduces risk - if you’re relying on a third-party library, but want to swap it out for another one, this should become relatively straightforward. If you make changes in an area, you will feel confident that these changes won’t affect anywhere else. Having simpler, smaller components will also mean it’s easier to write and run tests on them, as well as making things more reusable.
Achieve editor fluency
Being fluent with an editor basically involves knowing a lot of shortcuts. When you’re writing code, you want to spend less time thinking about *how* to write the code into your editor and more time spent being in the flow of writing the code. I know how to comment and un-comment a line, but I have no clue how to select a select a word at a time or line at a time (I just use my mouse to select things) so I know this is something I need to work on.
If you want a challenge, you could stop using your mouse or trackpad for a week, and only use the keyboard to code. The less painful way to achieve editor fluency is to ask yourself, as you code, if there’s a simpler way of doing the thing you’re doing. Then go and find that out, and start using it whenever you can. This may be a new keyboard shortcut, or it may be a new extension you can install on your IDE. If you can’t find a solution, you could even write your own extension.
Have an engineering daybook
The authors recommend carrying around a paper notebook, and using it to take notes every day with what you’ve been working on. It can also be a place where you store ideas. The benefit here is that you can look back on it later, and re-remember why you decided to do something the way you did. The act of writing a problem or solution down can also help you take a step back and realise if you’re doing something wrong.
The book specifically recommends using paper and not a digital solution - which is not something I’m sure I agree with. I do currently take some notes on my laptop when I’m stuck with something and find the solution later, which has been useful as ideas for blog posts, and I definitely want to keep this habit up. I might extend it to writing more of a daily log of what I’ve been working on.
Use property-based testing
When you write unit tests, you generally think about the ways your code could go wrong, and write tests to cover those cases. But what happens if you make an incorrect assumption while writing these tests, or don’t realise you’ve missed a specific edge case?
Enter property-based testing. Instead of providing one input and testing for one specific output, you’d provide a property (for example, when testing a sorting function the property would be asserting that the result is properly sorted) and then the test would test a bunch of different, random combinations to try and see if the property ever fails. Depending on the language you use, there will be probably be a property-testing library out there, e.g. JSVerify for JavaScript.
Originally posted at www.emgoto.com.
I recently read the book How to Take Smart Notes by Sönke Ahrens. It explores the note-taking method of a famous German sociologist Niklas Luhmann, who published a *huge* amount of work in his lifetime (70 books and 400+ articles) - and it was quite possibly due to the efficient way he took notes.
Although the book was primarily aimed at students and academics who have to write papers, I still gleaned some really good lessons from it that I think are applicable to developers, especially those who write blog posts about what they learn.
Write notes in your own words
When studying and making notes, a common approach is to copy down definitions of things straight from the textbook or learning resource that you are using. If you’re attending a lecture or listening to a course online, and are a super-fast typist, you might even be able to directly quote what your instructor is saying straight into your notes.
The problem that comes with writing notes this way is that you’ve been able to skip the work of actually understanding the content. If you go back and re-read your notes a couple of times, this will create the illusion of understanding (as you will be able to recall bits of it in your memory) but saying it in your own words takes a bit more thought and brainpower to do.
When writing your notes, it is important that you do the work upfront of understanding the meaning, by making sure they’re written in your own words. This will save you the hassle of trying to understand it later.
Where writing notes can turn into a problem
You probably will have some sort of notebook (whether it’s paper-based or digital) where you jot down all your notes. If you’re organised, you may even have some sort of tagging system too! Keeping notes is good practice, but problems can arise depending on what you do with the notes after you’ve written them.
Over time as you learn and note down new things, your collection of notes will grow bigger and bigger. It can start to be a bit overwhelming, especially if your notes are disjointed and all over the place without much clear organisation. If you’re looking through your notes for a new topic to blog about, it may be hard to find something worth blogging about.
Even worse - you may have documented the solution to a particularly gnarly problem you solved at work (which would make for some great blog content!) but after coming back to it later you’re finding it hard to turn it into a blog. What made solving this problem so difficult, exactly? Why did we need to solve it in the first place?
When you quickly jot down notes, you’ll probably skip writing down all of the details, because in that moment, you can remember all of it just fine. But when you come back to these notes later, you may have completely forgotten the context in which they were written, and thus these notes will lose some of their value.
Understanding and writing down your notes gets you two thirds of the way there. But there's a third thing you need to do to write truly effective notes. Step three involves something called a **slip-box**.
What is the slip-box (or Zettelkasten) method?
Soon after you’ve jotted down your notes you need to rewrite your notes into “permanent notes” that will live in your slip-box.
A slip-box, also known as a “card index” or “zettelkasten” in German, is where Niklas Luhmann would store all of his permanent notes on index cards. Today, you can also accomplish the same sort of thing thanks to using various software, some even specifically made for Zettelkasten.
Each of these notes shouldn’t be excessively long - Luhmann kept things succinct by only using one side of each index card. But at the same time, he made sure that the notes themselves were written properly with full sentences, and were able to be understood without any additional context.
As he created more notes, he would find links to other notes he had created, and with a numbering/lettering system would denote certain notes as “sub notes” of other notes. If a note was related to two separate notes, it might be made a sub note of one, and the linkage to the other note would be noted on the index card itself.
The act of writing these notes (properly) and finding the connections between them and other notes isn’t easy. It’s a lot harder than just jotting down notes in a notebook and calling it a day. But by doing this expensive brainpower up front, you’re essentially building up a library of interconnected knowledge from the ground-up.
As you build up your knowledge library and find the relations between bits of knowledge, the real beauty of this system is that it will organically let you find topics to write about - they essentially will have written themselves because you will have done the work upfront of explaining it in your own words, and connecting it to other notes in your slip-box.
Implementing the slip-box method as a developer
Prior to reading this book, my collection of notes was messily stored in Dropbox Paper without much categorisation, and missing lots of context. In some cases, it was just a link to an article or some documentation with a "TIL" written underneath it.
I've taken a little look around at what's available to store and write my notes in, and for now I've settled on Notion. I've started to make the effort to convert some of my "messy" notes into "proper" ones, and I'm finding that I'm actually skipping the act of putting the permanent notes into a slip-box and going straight to creating blog draft out of this content. So I can't yet comment on the effectiveness of properly using a slip-box but for me at least it is providing some results!
If I do find this approach useful in the long term, I'll be sure to write up a post detailing my experiences. In the meantime, I'd love to hear about your note-taking experiences - what does and doesn't work for you?
Thanks for reading!
Originally posted at www.emgoto.com.
I recently read the book How to Take Smart Notes by Sönke Ahrens. It explores the note-taking method of a famous German sociologist Niklas Luhmann, who published a *huge* amount of work in his lifetime (70 books and 400+ articles) - and it was quite possibly due to the efficient way he took notes.
Although the book was primarily aimed at students and academics who have to write papers, I still gleaned some really good lessons from it that I think are applicable to developers, especially those who write blog posts about what they learn.
Write notes in your own words
When studying and making notes, a common approach is to copy down definitions of things straight from the textbook or learning resource that you are using. If you’re attending a lecture or listening to a course online, and are a super-fast typist, you might even be able to directly quote what your instructor is saying straight into your notes.
The problem that comes with writing notes this way is that you’ve been able to skip the work of actually understanding the content. If you go back and re-read your notes a couple of times, this will create the illusion of understanding (as you will be able to recall bits of it in your memory) but saying it in your own words takes a bit more thought and brainpower to do.
When writing your notes, it is important that you do the work upfront of understanding the meaning, by making sure they’re written in your own words. This will save you the hassle of trying to understand it later.
Where writing notes can turn into a problem
You probably will have some sort of notebook (whether it’s paper-based or digital) where you jot down all your notes. If you’re organised, you may even have some sort of tagging system too! Keeping notes is good practice, but problems can arise depending on what you do with the notes after you’ve written them.
Over time as you learn and note down new things, your collection of notes will grow bigger and bigger. It can start to be a bit overwhelming, especially if your notes are disjointed and all over the place without much clear organisation. If you’re looking through your notes for a new topic to blog about, it may be hard to find something worth blogging about.
Even worse - you may have documented the solution to a particularly gnarly problem you solved at work (which would make for some great blog content!) but after coming back to it later you’re finding it hard to turn it into a blog. What made solving this problem so difficult, exactly? Why did we need to solve it in the first place?
When you quickly jot down notes, you’ll probably skip writing down all of the details, because in that moment, you can remember all of it just fine. But when you come back to these notes later, you may have completely forgotten the context in which they were written, and thus these notes will lose some of their value.
Understanding and writing down your notes gets you two thirds of the way there. But there's a third thing you need to do to write truly effective notes. Step three involves something called a **slip-box**.
What is the slip-box (or Zettelkasten) method?
Soon after you’ve jotted down your notes you need to rewrite your notes into “permanent notes” that will live in your slip-box.
A slip-box, also known as a “card index” or “zettelkasten” in German, is where Niklas Luhmann would store all of his permanent notes on index cards. Today, you can also accomplish the same sort of thing thanks to using various software, some even specifically made for Zettelkasten.
Each of these notes shouldn’t be excessively long - Luhmann kept things succinct by only using one side of each index card. But at the same time, he made sure that the notes themselves were written properly with full sentences, and were able to be understood without any additional context.
As he created more notes, he would find links to other notes he had created, and with a numbering/lettering system would denote certain notes as “sub notes” of other notes. If a note was related to two separate notes, it might be made a sub note of one, and the linkage to the other note would be noted on the index card itself.
The act of writing these notes (properly) and finding the connections between them and other notes isn’t easy. It’s a lot harder than just jotting down notes in a notebook and calling it a day. But by doing this expensive brainpower up front, you’re essentially building up a library of interconnected knowledge from the ground-up.
As you build up your knowledge library and find the relations between bits of knowledge, the real beauty of this system is that it will organically let you find topics to write about - they essentially will have written themselves because you will have done the work upfront of explaining it in your own words, and connecting it to other notes in your slip-box.
Implementing the slip-box method as a developer
Prior to reading this book, my collection of notes was messily stored in Dropbox Paper without much categorisation, and missing lots of context. In some cases, it was just a link to an article or some documentation with a "TIL" written underneath it.
I've taken a little look around at what's available to store and write my notes in, and for now I've settled on Notion. I've started to make the effort to convert some of my "messy" notes into "proper" ones, and I'm finding that I'm actually skipping the act of putting the permanent notes into a slip-box and going straight to creating blog draft out of this content. So I can't yet comment on the effectiveness of properly using a slip-box but for me at least it is providing some results!
If I do find this approach useful in the long term, I'll be sure to write up a post detailing my experiences. In the meantime, I'd love to hear about your note-taking experiences - what does and doesn't work for you?
Thanks for reading!
Originally posted at www.emgoto.com.
Nadia Eghbal's recent book Working in Public: The Making and Maintenance of Open Source Software, covers what the open source experience is like for maintainers today.
It ends with the following sentence:
“We don’t have all the answers yet, but I’m hoping this book helps point us towards the right questions.”
This felt like a very apt conclusion, for I did walk away from this book feeling a lot more sympathy for those who do work in open source, but also without any real answers or solutions for what we can do about open source.
This post is a summary of some of the things I learned from Nadia’s book. At around 250 pages it’s not too long of a read so I would definitely recommend buying the book for yourself if you have any interest in this topic.The open source community has grown friendlier, and more inclusive
Eghbal points out that open source has come a long way in becoming a more open and inclusive community. Repositories now have codes of conduct, and there is a culture of being generally welcoming and friendly towards first-time contributors. This contrasts with the earlier “benevolent dictators” of open source like Linus Torvalds (the creator of Linux) who in 2018 apologised for his many years of "unprofessional and uncalled for" behaviour.
I’ll admit gave me a chuckle when I turned the page to see Torvalds giving the finger, juxtaposed with Sindre Sorhus surrounded by Huskies.
Github is also credited for reducing the barrier to participating in open source. Since we have standardised on Github as the place most open source repositories live, this means users are more likely to be familiar with the interface (and to already have an account). This makes it a lot easier for users to open issues when they encounter bugs or have questions, as well as to raise pull requests to fix these bugs or add new features.
Popularity can lead to maintainer fatigue
The generally welcoming nature of open source combined with the ease by which users can create PRs or issues can result in a lot of work for maintainers (especially those who maintain a repository by themselves). They may feel pressured to respond to every issue and pull request received, and to spend time helping contributors to get their pull request to a state where it can be merged.
Of course, not all contributors are a burden. It may be that by taking the time to help a first-time contributor merge a pull request, they could go on to contribute more useful pull requests in the future. But if more than 50% of contributors are one-off contributors to a project, that can be a lot of time invested by maintainers that they're not going to see a return on.
This pressure can cause some maintainers to want to quit. However even quitting can be hard! Deleting a popular repository could “break the internet” as was the case with left-pad. And finding someone to take over your repository might mean needing to put your faith in a relative stranger, who could end up adding malicious code to steal your Bitcoins.
Should open source be a one-way mirror?
One of the potential suggestions Eghbal poses to this problem is to make open source a "one-way mirror". In practice, this would mean that users would be able to see the code, as well as any discussions that maintainers are having, but would no longer be able to open pull requests or issues asking for help.
Maintainers would be able to opt-in certain contributors who they know would bring value, or they could allow people who are sponsoring their project access as well.
This would drastically reduce the amount of time maintainers have to spend responding to users’ requests, and allow them to do more high-value work.
With the inclusive and welcoming nature of open source, there could be some anger directed towards maintainers who take this approach. I think it would be too drastic of a change to be widely adopted any time soon, but I think there's a lot of inspiration we can take from this idea. Maybe there's some sort of middle ground?
Looking for solutions
Eghbal has pointed out some of the problems plaguing open source today, but given this is a very hard problem to solve, understandably there are no perfect solutions yet.
To some extent, we can mitigate some of the busywork maintainers have to do by using bots and other automation (like running tests when contributors open PRs). Maintainers can also uphold a certain set of standards that a pull request must meet before it becomes reviewed, and provide clear documentation to help first-time contributors meet these standards.
Maintainers could also employ curators who could maintain a similar role to what moderators do on Twitch - weed out any low-value issues or pull requests, and surface to the maintainers only the issues and pull requests that are worth the attention.
As Github is the platform of choice for open source, maintainers are also reliant on Github to provide the features they need to work effectively. For example, users can now vote on issues by using the “thumbs up” emoji, but for a long time this feature was not available, and so maintainers had to deal with receiving notifications from users leaving “+1” comments.
## Conclusion
As someone who has dabbled a little bit in the open source community, Working in Public has provided me with a lot of food for thought, and definitely makes me more sympathetic towards maintainers!
The book feels especially relevant this month with Hacktoberfest, which has unfortunately caused a lot of difficulty for maintainers of open source projects.
I'm interested to see what direction the open source community takes into the future. I think the idea of curating issues/PRs on repositories (similar to Twitch moderation) could also be a great way for people to start contributing to an open source repository if they don't feel comfortable enough with the codebase, but want to help out.
Maybe there's some way we can crowdsource this and create some sort of platform so that maintainers can ask for help curating, and volunteers can step in. Could be interesting!
Originally posted at www.emgoto.com.
Nadia Eghbal's recent book Working in Public: The Making and Maintenance of Open Source Software, covers what the open source experience is like for maintainers today.
It ends with the following sentence:
“We don’t have all the answers yet, but I’m hoping this book helps point us towards the right questions.”
This felt like a very apt conclusion, for I did walk away from this book feeling a lot more sympathy for those who do work in open source, but also without any real answers or solutions for what we can do about open source.
This post is a summary of some of the things I learned from Nadia’s book. At around 250 pages it’s not too long of a read so I would definitely recommend buying the book for yourself if you have any interest in this topic.The open source community has grown friendlier, and more inclusive
Eghbal points out that open source has come a long way in becoming a more open and inclusive community. Repositories now have codes of conduct, and there is a culture of being generally welcoming and friendly towards first-time contributors. This contrasts with the earlier “benevolent dictators” of open source like Linus Torvalds (the creator of Linux) who in 2018 apologised for his many years of "unprofessional and uncalled for" behaviour.
I’ll admit gave me a chuckle when I turned the page to see Torvalds giving the finger, juxtaposed with Sindre Sorhus surrounded by Huskies.
Github is also credited for reducing the barrier to participating in open source. Since we have standardised on Github as the place most open source repositories live, this means users are more likely to be familiar with the interface (and to already have an account). This makes it a lot easier for users to open issues when they encounter bugs or have questions, as well as to raise pull requests to fix these bugs or add new features.
Popularity can lead to maintainer fatigue
The generally welcoming nature of open source combined with the ease by which users can create PRs or issues can result in a lot of work for maintainers (especially those who maintain a repository by themselves). They may feel pressured to respond to every issue and pull request received, and to spend time helping contributors to get their pull request to a state where it can be merged.
Of course, not all contributors are a burden. It may be that by taking the time to help a first-time contributor merge a pull request, they could go on to contribute more useful pull requests in the future. But if more than 50% of contributors are one-off contributors to a project, that can be a lot of time invested by maintainers that they're not going to see a return on.
This pressure can cause some maintainers to want to quit. However even quitting can be hard! Deleting a popular repository could “break the internet” as was the case with left-pad. And finding someone to take over your repository might mean needing to put your faith in a relative stranger, who could end up adding malicious code to steal your Bitcoins.
Should open source be a one-way mirror?
One of the potential suggestions Eghbal poses to this problem is to make open source a "one-way mirror". In practice, this would mean that users would be able to see the code, as well as any discussions that maintainers are having, but would no longer be able to open pull requests or issues asking for help.
Maintainers would be able to opt-in certain contributors who they know would bring value, or they could allow people who are sponsoring their project access as well.
This would drastically reduce the amount of time maintainers have to spend responding to users’ requests, and allow them to do more high-value work.
With the inclusive and welcoming nature of open source, there could be some anger directed towards maintainers who take this approach. I think it would be too drastic of a change to be widely adopted any time soon, but I think there's a lot of inspiration we can take from this idea. Maybe there's some sort of middle ground?
Looking for solutions
Eghbal has pointed out some of the problems plaguing open source today, but given this is a very hard problem to solve, understandably there are no perfect solutions yet.
To some extent, we can mitigate some of the busywork maintainers have to do by using bots and other automation (like running tests when contributors open PRs). Maintainers can also uphold a certain set of standards that a pull request must meet before it becomes reviewed, and provide clear documentation to help first-time contributors meet these standards.
Maintainers could also employ curators who could maintain a similar role to what moderators do on Twitch - weed out any low-value issues or pull requests, and surface to the maintainers only the issues and pull requests that are worth the attention.
As Github is the platform of choice for open source, maintainers are also reliant on Github to provide the features they need to work effectively. For example, users can now vote on issues by using the “thumbs up” emoji, but for a long time this feature was not available, and so maintainers had to deal with receiving notifications from users leaving “+1” comments.
## Conclusion
As someone who has dabbled a little bit in the open source community, Working in Public has provided me with a lot of food for thought, and definitely makes me more sympathetic towards maintainers!
The book feels especially relevant this month with Hacktoberfest, which has unfortunately caused a lot of difficulty for maintainers of open source projects.
I'm interested to see what direction the open source community takes into the future. I think the idea of curating issues/PRs on repositories (similar to Twitch moderation) could also be a great way for people to start contributing to an open source repository if they don't feel comfortable enough with the codebase, but want to help out.
Maybe there's some way we can crowdsource this and create some sort of platform so that maintainers can ask for help curating, and volunteers can step in. Could be interesting!
Originally posted at www.emgoto.com.
Originally published in the late 1990s, The Power of Now was written after its author, Eckhart Tolle, had an epiphany at age 29 and became “enlightened”. The book achieved huge success once it was recommended by popular talkshow host Oprah Winfrey.
The author holds some very strong beliefs which almost feel like his own religion in a way. This may turn you off if you are fairly anti-religious or already follow a religion.
He also makes some (to me, dubious) claims about his teachings. For example, that it will help you age slower, and strengthen your immune system.
(Although I was left feeling sceptical as I read his claims, I am open to acknowledging that his teachings could help lower your stress, which in turn probably helps you to stay healthy and live a little bit longer).
Nonetheless, for all that I disliked about the book I still enjoyed it enough to write this blog post about it!Acknowledge the thoughts in your head, and let go
People spend almost all of their time thinking. Sometimes, we might dwell on things that have happened to us in the past, or worry about things that might happen in the future.
Holding onto these thoughts isn’t very useful. It prevents us from enjoying the “now” because we spend so much time stuck in the past or the future.
When these thoughts come into your head, you should take a step back and observe the thought impartially. Don’t beat yourself up about these negative thoughts either (because that’s just creating more negative thoughts). Acknowledge it, and by acknowledging it you’ll have an easier time of letting it go.
In a way, a lot of what Eckhart Tolle talks about is very similar to the concept of mindfulness, which you may be familiar with. Using meditation apps like [Headspace](https://www.headspace.com/mindfulness) can help you to hone your mindfulness skill, even for as little as 5 - 10 minutes a day.
Don’t yearn for happiness in the future, because you’re never going to get there
This is something I’m very guilty of. It’s very easy to fall into the trap of thinking “I’ll be happy once I attain X” or “I’ll be happy when I become Y”. But the truth is that you’ll reach that milestone, and then you’ll set yourself another one! You’ll forever be chasing happiness in the future, when instead you should be focusing on happiness in the “now”.
Being happy today is easier said than done. I recently listened to an audiobook, Habits for Happiness, which gave a couple of tips:
* Every day, think of three things that you are grateful for
* Make sure to get enough sleep, and regularly exercise
* Create a vision board for yourself that outlines all the things you want to achieve to be happy
* Set yourself goals to work towards achieving your vision
I love goal setting and creating vision boards, although it technically does seem to conflict with what Eckhart Tolle talks about. I think the way to approach it is that it’s okay to have a vision, but you have to enjoy the process of getting there, rather than putting off the enjoyment for until you get there.
## Conclusion
As much as I rolled my eyes at some of what Tolle had to say, I still did feel that this book had an impact on me. Especially during this pandemic I sometimes do feel myself struggling a little bit and this book was a helpful reminder to spend less time worrying or yearning and to try to enjoy the “now”.
From looking at its reviews on Goodreads, if you are already fairly familiar with meditation, zen or other spiritual books I would give this one a miss. However if you are fairly new to the topic (like me) and are open to books on spirituality or willing to look past the dodgy bits, I would recommend giving this book a go.
Originally posted at www.emgoto.com.
Originally published in the late 1990s, The Power of Now was written after its author, Eckhart Tolle, had an epiphany at age 29 and became “enlightened”. The book achieved huge success once it was recommended by popular talkshow host Oprah Winfrey.
The author holds some very strong beliefs which almost feel like his own religion in a way. This may turn you off if you are fairly anti-religious or already follow a religion.
He also makes some (to me, dubious) claims about his teachings. For example, that it will help you age slower, and strengthen your immune system.
(Although I was left feeling sceptical as I read his claims, I am open to acknowledging that his teachings could help lower your stress, which in turn probably helps you to stay healthy and live a little bit longer).
Nonetheless, for all that I disliked about the book I still enjoyed it enough to write this blog post about it!Acknowledge the thoughts in your head, and let go
People spend almost all of their time thinking. Sometimes, we might dwell on things that have happened to us in the past, or worry about things that might happen in the future.
Holding onto these thoughts isn’t very useful. It prevents us from enjoying the “now” because we spend so much time stuck in the past or the future.
When these thoughts come into your head, you should take a step back and observe the thought impartially. Don’t beat yourself up about these negative thoughts either (because that’s just creating more negative thoughts). Acknowledge it, and by acknowledging it you’ll have an easier time of letting it go.
In a way, a lot of what Eckhart Tolle talks about is very similar to the concept of mindfulness, which you may be familiar with. Using meditation apps like [Headspace](https://www.headspace.com/mindfulness) can help you to hone your mindfulness skill, even for as little as 5 - 10 minutes a day.
Don’t yearn for happiness in the future, because you’re never going to get there
This is something I’m very guilty of. It’s very easy to fall into the trap of thinking “I’ll be happy once I attain X” or “I’ll be happy when I become Y”. But the truth is that you’ll reach that milestone, and then you’ll set yourself another one! You’ll forever be chasing happiness in the future, when instead you should be focusing on happiness in the “now”.
Being happy today is easier said than done. I recently listened to an audiobook, Habits for Happiness, which gave a couple of tips:
* Every day, think of three things that you are grateful for
* Make sure to get enough sleep, and regularly exercise
* Create a vision board for yourself that outlines all the things you want to achieve to be happy
* Set yourself goals to work towards achieving your vision
I love goal setting and creating vision boards, although it technically does seem to conflict with what Eckhart Tolle talks about. I think the way to approach it is that it’s okay to have a vision, but you have to enjoy the process of getting there, rather than putting off the enjoyment for until you get there.
## Conclusion
As much as I rolled my eyes at some of what Tolle had to say, I still did feel that this book had an impact on me. Especially during this pandemic I sometimes do feel myself struggling a little bit and this book was a helpful reminder to spend less time worrying or yearning and to try to enjoy the “now”.
From looking at its reviews on Goodreads, if you are already fairly familiar with meditation, zen or other spiritual books I would give this one a miss. However if you are fairly new to the topic (like me) and are open to books on spirituality or willing to look past the dodgy bits, I would recommend giving this book a go.
Originally posted at www.emgoto.com.
The Checklist Manifesto may look like yet another self-help or productivity book. But I found it to be a well-written book on the power of the humble checklist.
Its author, Atul Gawande, is a surgeon who has helped to create a checklist now used by hospitals worldwide. When hospitals began using the checklist, they reduced deaths and major complications during surgery by more than 30% (wow!)
The checklist itself is simple, only covering the most important steps during a surgery. Think things like confirming a patient's identity, or making sure they've received antibiotics. These key steps might _seem_ trivial, but on average, one of these steps was missed in two thirds of surgery patients.
In the book, Gawande also takes the time to explore how other industries use checklists, for flying planes, building skyscrapers or running investment firms. Altogether, he made a pretty compelling case for the power of checklists.
The 3 steps to implementing a successful checklist
1. Keep the checklists usable. In a high-stakes situation like surgery or flying an airplane, you want to keep your checklists brief and to the point. Only cover the most important tasks. If you miss these tasks, they could cause major or fatal consequences. This also ensures that people will actually _use_ the checklist and follow all the steps.
2. Have the checklists broken down into subsections, to occur before key trigger points. In a surgery, that might be right before you give a patient anaesthesia, or the moment before the first incision. Breaking it down makes it less overwhelming, and a trigger makes it easier to remember when to do a checklist.
3. Test the checklist, and refine it. A checklist is never going to be right on the first go. Through many iterations, you’ll be able to amend the bits that are confusing, or add and remove sections as needed.
How developers can use checklists
The book proves that checklists work in medicine and other industries, but what about for developers? A developer’s checklist could include things like:
* Writing test notes before a task, or talking through your approach with the stakeholder or another developer. This way, you can make sure that all your assumptions are correct.
* Making sure all tests pass before raising a pull request.
* Showing your work to another developer before letting the code hit production, to double-check for bugs.
It might seem silly to have such a checklist, but the idea here is to keep the tasks simple. If you miss them (and let’s face it, sometimes we do) they could have big consequences. Misunderstanding a requirement from a stakeholder could force you to rewrite part of your code. And if you shipped a bug to production you could have some angry customers on your hands.
Conclusion
The Checklist Manifesto was a fun read, with lots of interesting examples of how different industries are using checklists. Among the many productivity books I've read over the years, this one is up there! I can definitely see the value this could add to my own life - I just need to figure out what these checklists could look like.
Originally posted at www.emgoto.com.
The Checklist Manifesto may look like yet another self-help or productivity book. But I found it to be a well-written book on the power of the humble checklist.
Its author, Atul Gawande, is a surgeon who has helped to create a checklist now used by hospitals worldwide. When hospitals began using the checklist, they reduced deaths and major complications during surgery by more than 30% (wow!)
The checklist itself is simple, only covering the most important steps during a surgery. Think things like confirming a patient's identity, or making sure they've received antibiotics. These key steps might _seem_ trivial, but on average, one of these steps was missed in two thirds of surgery patients.
In the book, Gawande also takes the time to explore how other industries use checklists, for flying planes, building skyscrapers or running investment firms. Altogether, he made a pretty compelling case for the power of checklists.
The 3 steps to implementing a successful checklist
1. Keep the checklists usable. In a high-stakes situation like surgery or flying an airplane, you want to keep your checklists brief and to the point. Only cover the most important tasks. If you miss these tasks, they could cause major or fatal consequences. This also ensures that people will actually _use_ the checklist and follow all the steps.
2. Have the checklists broken down into subsections, to occur before key trigger points. In a surgery, that might be right before you give a patient anaesthesia, or the moment before the first incision. Breaking it down makes it less overwhelming, and a trigger makes it easier to remember when to do a checklist.
3. Test the checklist, and refine it. A checklist is never going to be right on the first go. Through many iterations, you’ll be able to amend the bits that are confusing, or add and remove sections as needed.
How developers can use checklists
The book proves that checklists work in medicine and other industries, but what about for developers? A developer’s checklist could include things like:
* Writing test notes before a task, or talking through your approach with the stakeholder or another developer. This way, you can make sure that all your assumptions are correct.
* Making sure all tests pass before raising a pull request.
* Showing your work to another developer before letting the code hit production, to double-check for bugs.
It might seem silly to have such a checklist, but the idea here is to keep the tasks simple. If you miss them (and let’s face it, sometimes we do) they could have big consequences. Misunderstanding a requirement from a stakeholder could force you to rewrite part of your code. And if you shipped a bug to production you could have some angry customers on your hands.
Conclusion
The Checklist Manifesto was a fun read, with lots of interesting examples of how different industries are using checklists. Among the many productivity books I've read over the years, this one is up there! I can definitely see the value this could add to my own life - I just need to figure out what these checklists could look like.
Originally posted at www.emgoto.com.
On Writing Well's key message is to be economical in your writing. Find the most efficient way to express your ideas. Skip the fancy prose, because your readers will see through its pretentiousness, and instead focus on expressing your ideas clearly.
As a writer you might worry that by doing this, you will lose any chance standing out and having your own unique writing style. But like carpentry, you have to start from the foundations. And over time, your style will grow.
The book reiterates some of the advice laid out in the Elements of Style:
* Use active verbs
* Cut out most adverbs (e.g. “blared loudly” and “blared” mean the same thing)
* Skip little qualifiers like “a little” or “sort of” as it reduces your authoritativeness
Some more general writing tips include:
* Practice writing every day
* Read your writing out loud to make sure it flows well
* Write for yourself
> “If you write for yourself, you'll reach the people want to write for.”
There are chapters on writing about different genres of non-fiction writing. On travel writing: skip the cliches. Everyone already knows the Grand Canyon is majestic. What's more interesting to your readers is your own experiences. The book covers other topics like business, sports and memoirs. For me, these were the most boring since I had no interest in these genres.
Something I have a bad habit of doing is using exclamation points, and Zinsser discourages use of this as well. Your readers are smart enough to pick up on when something is exciting or unusual, without you having to point it out to them with a “!”.
The only dated part of this book is the use of “he” as a default when talking about hypothetical situations. As part of the 30th Anniversary Edition, the author says he has replaced 300+ usages of “he”, since many women brought it up to him after they had read the book. However he didn't replace them all, and disappointingly he says:
> “But let's face it: the English language is stuck with the generic masculine. To turn every ‘he' into a ‘he or she' . . . would clog the language.”
Otherwise, this book is still quite relevant today, and I would definitely recommend it for serious writers. For a hobby writer like me, I would have preferred it to be a little bit shorter.
Originally posted at www.emgoto.com.
On Writing Well's key message is to be economical in your writing. Find the most efficient way to express your ideas. Skip the fancy prose, because your readers will see through its pretentiousness, and instead focus on expressing your ideas clearly.
As a writer you might worry that by doing this, you will lose any chance standing out and having your own unique writing style. But like carpentry, you have to start from the foundations. And over time, your style will grow.
The book reiterates some of the advice laid out in the Elements of Style:
* Use active verbs
* Cut out most adverbs (e.g. “blared loudly” and “blared” mean the same thing)
* Skip little qualifiers like “a little” or “sort of” as it reduces your authoritativeness
Some more general writing tips include:
* Practice writing every day
* Read your writing out loud to make sure it flows well
* Write for yourself
> “If you write for yourself, you'll reach the people want to write for.”
There are chapters on writing about different genres of non-fiction writing. On travel writing: skip the cliches. Everyone already knows the Grand Canyon is majestic. What's more interesting to your readers is your own experiences. The book covers other topics like business, sports and memoirs. For me, these were the most boring since I had no interest in these genres.
Something I have a bad habit of doing is using exclamation points, and Zinsser discourages use of this as well. Your readers are smart enough to pick up on when something is exciting or unusual, without you having to point it out to them with a “!”.
The only dated part of this book is the use of “he” as a default when talking about hypothetical situations. As part of the 30th Anniversary Edition, the author says he has replaced 300+ usages of “he”, since many women brought it up to him after they had read the book. However he didn't replace them all, and disappointingly he says:
> “But let's face it: the English language is stuck with the generic masculine. To turn every ‘he' into a ‘he or she' . . . would clog the language.”
Otherwise, this book is still quite relevant today, and I would definitely recommend it for serious writers. For a hobby writer like me, I would have preferred it to be a little bit shorter.
Originally posted at www.emgoto.com.
DNF at 50%
I gave this a good crack but it felt too dense with all the characters and plot, and hard to keep up with / actually enjoy reading.
DNF at 50%
I gave this a good crack but it felt too dense with all the characters and plot, and hard to keep up with / actually enjoy reading.
Abandoned at 35%. Went through from Warren's childhood through to his life in the early 1970s. This is a huge 800+ page book and unfortunately I'm not that interested in finance or Warren Buffet to want to read all of it.
Buffett gave the author the go-ahead to be brutally honest and it shows. The early pages don't paint a very flattering picture of him. He comes across like a manchild (if I'm being honest). He's very picky with his food, to the point where when he stays out of town at a friend's mum's place (and this is when he's an adult by the way) she cooks him hamburgers for breakfast (!) His wife was doing an amazing job of basically propping him up and allowing him to do the one thing he was good at. This singular focus on money though meant he wasn't really paying enough attention to his wife and kids.
Although he's super money-oriented he's also very concerned about what other people think of him and possibly some loyalty comes into play too. So he's not a complete dick to other people in his pursuit of money. e.g. he wouldn't fire an entire factory worth of people just to make a couple extra bucks. He also did (maybe grudgingly) let his wife spend some of his money, so he wasn't a completely stingy guy either.
Of course since I only got a third of the way in (and there are 40 more years of his life covered in the book, I'm assuming he did grow as a person and a lot more good points happened further on. e.g. he did force his town's country club to start allowing Jewish members.
Abandoned at 35%. Went through from Warren's childhood through to his life in the early 1970s. This is a huge 800+ page book and unfortunately I'm not that interested in finance or Warren Buffet to want to read all of it.
Buffett gave the author the go-ahead to be brutally honest and it shows. The early pages don't paint a very flattering picture of him. He comes across like a manchild (if I'm being honest). He's very picky with his food, to the point where when he stays out of town at a friend's mum's place (and this is when he's an adult by the way) she cooks him hamburgers for breakfast (!) His wife was doing an amazing job of basically propping him up and allowing him to do the one thing he was good at. This singular focus on money though meant he wasn't really paying enough attention to his wife and kids.
Although he's super money-oriented he's also very concerned about what other people think of him and possibly some loyalty comes into play too. So he's not a complete dick to other people in his pursuit of money. e.g. he wouldn't fire an entire factory worth of people just to make a couple extra bucks. He also did (maybe grudgingly) let his wife spend some of his money, so he wasn't a completely stingy guy either.
Of course since I only got a third of the way in (and there are 40 more years of his life covered in the book, I'm assuming he did grow as a person and a lot more good points happened further on. e.g. he did force his town's country club to start allowing Jewish members.
I made it through 230/480 pages before I had to give up. Too dense and not very fun to read! All I knew about Wells was that he had written War of the Worlds so it was interesting to learn he was pretty progressive for his time, super influential and wrote a big wide range of stuff.
I made it through 230/480 pages before I had to give up. Too dense and not very fun to read! All I knew about Wells was that he had written War of the Worlds so it was interesting to learn he was pretty progressive for his time, super influential and wrote a big wide range of stuff.
DNF - the book talks about using your time wisely, and I don't think reading this book is worth it. Very shallow anecdotes and examples. Maybe worth reading if you have a problem saying “no” to things and really need a kick up the butt.
DNF - the book talks about using your time wisely, and I don't think reading this book is worth it. Very shallow anecdotes and examples. Maybe worth reading if you have a problem saying “no” to things and really need a kick up the butt.
DNF this one. Too many cliches and the plot twist is fairly obvious.
DNF this one. Too many cliches and the plot twist is fairly obvious.
Kinda boring so DNF at 50%.
Kinda boring so DNF at 50%.
DNF at 50% - can't put my finger on it but the writing style was just not good. Too confusing, maybe?
DNF at 50% - can't put my finger on it but the writing style was just not good. Too confusing, maybe?
DNF @ 50%
Very quirky, hitchhikers guide-esque book about a guy taking over his uncle's company and trying to become a super villain. Not really vibing with it, too quirky for me.
DNF @ 50%
Very quirky, hitchhikers guide-esque book about a guy taking over his uncle's company and trying to become a super villain. Not really vibing with it, too quirky for me.
DNF at 25% - I was a big fan of Martha Wells' sci-fi so I was keen to give this fantasy book a go, but I found the plot to be quite confusing and it wasn't really hooking me :(
DNF at 25% - I was a big fan of Martha Wells' sci-fi so I was keen to give this fantasy book a go, but I found the plot to be quite confusing and it wasn't really hooking me :(
Abandoned 30% in - I think I was about 10 years too late with this book. It was filled with a lot of ways employers could “nudge” their employees, but I was more interested in how I could nudge myself and so the book didn't really grip me.
Abandoned 30% in - I think I was about 10 years too late with this book. It was filled with a lot of ways employers could “nudge” their employees, but I was more interested in how I could nudge myself and so the book didn't really grip me.
Thought I'd try pick this up cos I vaguely remember Anne McCraffrey did a bunch of dragon fantasy books and this one's a scifi, but I DNF pretty early on - kinda like slave girl meets alien boy? But very cringe. Was written in the 90s and I feel like it shows.
Thought I'd try pick this up cos I vaguely remember Anne McCraffrey did a bunch of dragon fantasy books and this one's a scifi, but I DNF pretty early on - kinda like slave girl meets alien boy? But very cringe. Was written in the 90s and I feel like it shows.
DNF at 40%. The book goes for a very feminist, anti-men vibe (there are still good male characters though) and centres around some women who come into their powers at middle age. However it felt a bit too cringey for me to enjoy.
DNF at 40%. The book goes for a very feminist, anti-men vibe (there are still good male characters though) and centres around some women who come into their powers at middle age. However it felt a bit too cringey for me to enjoy.
Abandoned at 50%. The author is a tad too arrogant for my liking and his constant referring to people as “he” tipped me over the edge. I tried to push through but the content wasn't really hooking me either.
E.g. in a scenario where you're asked to imagine buying a new car - “People will think, Hey, he has a great car”. No they wont!!
Or “the ultimate test of whether you like an author is if you've reread him” - what about the women??
He also liked to diss people in certain professions “we humans have the largest cortex, followed by bank executives, dolphins, and our cousins the apes” which I get he's trying to be funny but it's really not.
Another notable “yikes” moment was when he said that attending social events is worth it for the networking and the ideas you'll get, but “if you are autistic, send one of your associates to these events” (I guess people with autism can't network?)
Abandoned at 50%. The author is a tad too arrogant for my liking and his constant referring to people as “he” tipped me over the edge. I tried to push through but the content wasn't really hooking me either.
E.g. in a scenario where you're asked to imagine buying a new car - “People will think, Hey, he has a great car”. No they wont!!
Or “the ultimate test of whether you like an author is if you've reread him” - what about the women??
He also liked to diss people in certain professions “we humans have the largest cortex, followed by bank executives, dolphins, and our cousins the apes” which I get he's trying to be funny but it's really not.
Another notable “yikes” moment was when he said that attending social events is worth it for the networking and the ideas you'll get, but “if you are autistic, send one of your associates to these events” (I guess people with autism can't network?)