Pay It Forward

It’s worth noting that this conversation was tailored to the person I was writing to. An interest in GitHub, and a desire to work in the open source community to learn what it’s like.

Here’s what I wrote after a 30 minute conversation.

Nice to meet you on the phone today. Some pointers to share. Definitely reflect my opinion and point of view. You should absolutely find and talk to software engineers in the the workplace. I just play at software engineering ;-)

1. Get a GitHub account and learn how to use GitHub. https://skills.github.com/
2. Learn basic git workflows. Like maybe the first three chapters of this. But there are a ton of good resources online.
3. Find an open source project that interests you. Fix a tiny issue to learn how to contribute to an open source project.
   1. Example: https://goodfirstissue.dev/language/python contains what are commonly called “good first issues”.
   2. https://github.com/matplotlib/matplotlib/labels/Good%20first%20issue > This shows how to search in the Matplotlib repository (‘repo’) for issues that the maintainers think are good for first-timers.
4. Write something small to learn how to do software engineering
   1. Write a little bit of software that does something interesting but trivial.
   2. Make sure it’s well documented so that someone else can get up and running without talking with you. A good README.md file at the root of your git repository is a great start!
   3. Figure out how to run your suite of tests, or build, or something, every time you commit code: continuous integration (CI).
5. Write down what you learn, but keep the bar very low.
   1. I got the idea from Simon Willison (Python dev extraordinaire) https://simonwillison.net/tags/weeknotes/. He basically said, “just write it and hit publish. don’t have a quality bar to write down things you learn”.
   2. Use those links in your resume. See my attached resume. I link to examples of things I’ve written, learned, even like 15 years ago I wrote a crappy bit of Ruby code to do an experiment. Literally still refer to that today! This is the resume I used to get my gig at GitHub – just shamelessly linking to things I’ve written, no matter how half-baked. You see the links in the “technical skills” section are to the most basic things. But it proves that I’ve done something. As a software engineer the bar might [will!] be [much!!!] higher for you than me…
6. If you’re looking for an engineer-y way to write “today I learned” or similar, try using a developer-centric approach to publishing a blog. It’s more work, but you learn stuff and that’s the point.
   1. For example, I wrote my own personal website using some awesome software called Hugo. Check out the source code (and the README) for my own website.
   2. Every time I write and post a little article, and git push it to GitHub, it gets built and published automatically. Total overkill, but shows that I’ve done the work.

I think that’s a good basic start. Again, that’s absolutely my opinion and you should talk to other folks to get a balanced view.

By the way you can see the resume that I shared right on this site.