DEV Community: Corbin Taylor

Long Time, No See.

Corbin Taylor — Sun, 05 May 2024 06:29:46 +0000

Hello DEV,

I know it's been quite some time since I've really wrote anything on here. I guess it's time to come out from under my rock that I've been living under.

It's been a busy couple of years, and an exhausting career so far in Tech.

The following is a brief summary of things, thus far. I cannot go into detail about the systems I worked on, so sorry to disappoint.

AWS

My first two years (2020-2022) in Tech were like trying to drink from a fire hose. I was a junior SDE at AWS, and it was some of the most fun yet challenging work I've done in my life. To describe it as a crucible would not be an understatement, but I learned a lot, both professionally and about myself. To top it off, it was also during the height of the COVID-19 pandemic, which I feel put everything on-edge.

Despite AWS being a cloud provider, this team managed a sizable back-end Spring codebase that ran on baremetal. The frontend was initially Ruby-on-Rails, but that was eventually replaced by React. There was also a menagerie of Ruby, Python, and Java ops scripts.

I was on one of those teams at AWS that nearly everyone at the company relied on; if we went down, everyone was down. encountering some awful people (not naming names). We averaged approximately 30+ high-severity tickets every week, which resulted in some very "eventful" on-call rotations.

Work was hard, hours were long, and I pushed myself beyond what I'd ever done before. I met some great people (some of whom I can say are some of my dearest friends), while also encountering some awful people (not naming names).

I discovered that I was tougher than I ever thought I could be.

I also learned the importance of being kind to myself, and to allow myself to be a work-in-progress. I'm still a work-in-progress, and always will be; we are always in the process of becoming.

I also learned that I needed to allow myself to have a work-life balance. While there are those that will chastise such notions, not allowing that balance will burn you out.

I burnt myself out. I'm still recovering, but I can feel myself breathe lighter every day.

Meditation. Music. Reading. Trying to just remember to be happy in the moment.

Capital One

In November 2022, I started at Capital One as a Software Engineer, at the Senior Associate level. I started working with containerized Springboot applications and Kafka, but have since migrated to Go and AWS Lambda.

I've continued to grow, but at a much more sustainable rate, and I am quite content with my team. While work can sometimes be heavy, my team and company seems to understand that people are overall happier and more productive when they are allowed to live healthy, balanced lives.

Last month, after a big production release, my team had our first big get together. After years of travel restrictions, remote working, and team de-centralization, it was nice to finally see everyone in person.

Surprisingly, not everyone is just a 2D Zoom avatar!

Remote-work jokes aside, my anxiety and introverted nature makes working from home so much easier.

Conclusion

I wasn't quite sure what I wanted to get across with this post, but I felt like typing tonight and see where it went.

Now then, DEV, I need to go to bed. There was a time when I would stay up to all hours of the night to get things done.

That younger version of myself was a fool, and he should go to sleep. Like I will now.

An Introduction To PGP

Corbin Taylor — Sun, 16 Jan 2022 17:40:42 +0000

I am someone who has been interested in privacy and security for most of my adult life. I am also someone who can be described as, perhaps, a tiny bit paranoid at times. Are these things related? Probably.

However, you do not have to be paranoid to want to be secure and to have your privacy maintained online. Even if you don't have something to hide, that doesn't mean that your friends don't.

What if you're talking to someone who is standing up for women's rights or is LGBTQ+ in a country where such things are socially (or even legally) dangerous? If you don't keep yourself secure, then you could become their vulnerability.

I'm not trying to scare you, and I'm certainly not trying to turn you into some conspiracy theorist. I'm just trying to point out that, even if you have nothing to hide, that you should be conscious of your online security posture.

So, you may ask now, what should I do about it?

There are many good security and privacy tools and services out there (which I may expand upon in a future post), but today I want to talk about something that I have been playing around with recently: PGP.

What Is PGP?

PGP (short for "Pretty Good Privacy") is an protocol used to encrypt, decrypt, and sign data. It's widely used, and if properly implemented, is considered a great way to protect yourself and your private discussions online.

The idea behind this is that, you will start with a public and a private key that are paired. The public key is something that you can share openly with people, while the private key you should keep hidden.

The public key allows others to mark you as the recipient of a document, encrypting it and saying that only you can decrypt it.

The private key allows you to confirm who you say you are, and decrypt the message that was sent to you.

Furthermore, say you want to send a message to someone, and you want to make sure that they know you are who you say you are. PGP allows you to sign the document using your private key which the other person can confirm you are who you say you are by comparing it to your public key.

If you want a high-level description in video form, Computerphile has nice video here.

Where Do You Get PGP?

The modern incarnation of this protocol, OpenPGP, was implemented by the Free Software Foundation in GPG ("GnuPG" or "GNU Privacy Guard"). If you are on Mac OS X, the easiest way for you to get GPG is through GPG Tools.

How Do You Use PGP/GPG?

Now that we have gone over "what" PGP and GPG are, I want to go over some of the basic usage.

This tutorial will only really scratch the surface, but I hope that I can at least teach you some things that can help you keep private things private.

Some Notes Before We Begin

For the rest of this article, I am going to assume that you have installed GPG, which as explained has implemented implemented OpenPGP. I will be showing you examples via the terminal.

In my case, I am a Mac OS X user and I will be showing examples via my preferred terminal, iTerm2 that uses zsh that has been customized with Oh My Zsh. My Oh My Zsh theme is af-magic with the synthwave-everything iTerm2 theme.

If you want to know more about terminal customization, comment below or reach out to me on my Twitter.

Getting Into The Terminal And Verifying Installation

To start with, you will need your terminal open and GPG installed (see above).

Once you have your terminal open, you can confirm that you have GPG installed by doing the which gpg command that shows the file path.

The first, and incredibly useful command to know is gpg --help which is gives you a list of the available commands and the various flags associated with them. It's especially handy if you ever forget something (which I do all the time).

Creating Your First Public/Private Key Pair

Once you have made sure that you can use GPG and have taken some time to read some of the help document, it's time to generate your first key pair.

Run the command gpg --full-generate-key, and you will be prompted about which algorithm you wish to use to generate your public and private keys, as well as the number of bits of information (or entropy that they will contain.

A theoretical discussion of what this all means is well beyond the scope of this blog post, but practically speaking, you can think of entropy being associated with the chance that a hostile actor could break the encryption via brute force repetition. The more bits, the harder it is for them to break the encryption.

In this case, I have chosen (1) RSA and RSA and 4096 bits.

After choosing the algorithm, you will then be prompted about the expiration date of your key-pair. You can choose a range from days to years (e.g., 2y), or to not have an expiration date at all (i.e., 0).

After that, you will be asked to generate a UID for the key, which is a combination of your name, your email that you want associated with the key, and some optional comment. This metadata will be a way of telling others who you are claiming to be.

In this case, I wrote my name (Corbin), the email (cjtaylor1990@dev.to), and my comment is something unquestionably true, which is that I love coffee and cats.

Finally, you will be prompted to give a pin to be associated with the private key. Any time you try to use the private key, you will be asked for the key pin.

For my case, I used a 40 character string that I randomly generated using 1Password. Alternatively, if you don't have a way to generate and store passwords electronically, you could use diceware to generate passwords and then store it on a piece of paper in your wallet or a safe.

After giving the pin code, gpg will generate the key pair and will give you a confirmation, as well as importing the public and private keys into your GPG key ring to be used later. The GPG key ring is simply the way that GPG stores and manages PGP keys on your local machine.

Notice in the picture above that there is a long alphanumeric string (212CF1042D88FFF461A62B76811A3B169B7EA4B7) above the uid. This is a unique identifier known as the key fingerprint and the last 8 values in the string, 9B7EA4B7 is the key ID.

To confirm that you now have the key in your key ring, you can use gpg --list-keys. You can list the specific key that you just generated by specifying the email, the key ID, or the finger print values as arguments. Alternatively, you can just use the command as is to list all of the keys that are listed on your key ring.

How To Encrypt A File That Is For Your Eyes Only

Now that you have a public/private key pair, you can actually start to do basic encryption/decryption. For example, say that you have a message that is for your eyes only. We could put that into a text file and encrypt it using the key that you just created.

First, you will need such a file. An easy way to create such a text file would be to use the echo command and then send it to an output file (e.g., test.txt) using the output operator (>).

For example, echo Hello, PGP! > test.txt. This will generate a test.txt file with your secret phrase, Hello, PGP! inside of it.

You can then confirm that the file contains the message using the cat command.

). This will output a text file at the path specified (e.g., test.txt) with the output inside of it. You can see what's inside of the file using the cat command. In this case, we see that you find "Hello, PGP!" inside of the file."/>

Now that you have your text file with your super secret hidden message, you can then encrypt it using gpg --encrypt and specifying yourself as the recipient with the --recipient flag.

In this case, that would be gpg --encrypt --recipient cjtaylor1990@dev.to test.txt. This will output an encrypted file, test.txt.gpg which you can check the contents of with cat.

If you see a garbled mess, then CONGRATULATIONS! You have created an encrypted message, and if you cannot currently read it, then hackers (or the NSA) likely can't easily read it either.

Now, if all we could do is encrypt the message, then that's not very useful. You want to come back later and decrypt the message!

You see, by encrypting this file this way, we have used your public key (the one that you can give to others) to encrypt a message specifies that only the real you can decrypt.

Thankfully, this is where the private key comes in! This also shows why it is VERY important not to share your private key with others.

Your private key (protected by your key pin) is the means by which you prove that you are the owner of the public key. The real you.

Since you have the private key on your GPG key chain, all you would have to do is use gpg --decrypt on the encrypted file, and it will then print the secret message to the screen along with the recipient (you). Note that you will be prompted (via popup) for your key pin before your private key can be used.

Furthermore, you can use the output (>) operation to put the secret message into a file that you specify.

For example:
gpg --decrypt test.txt.gpg > test.txt.clear
where I have chose the '.clear' file suffix to represent a clear-text file (as compared to an encrypted file).

Importing A Friends Public Key To Your Key Chain

Now, encrypting messages to yourself is nice, but what if you could encrypt messages to others? Well, you can! But first, we need another friend that uses PGP.

Let's say my awesome friend @pachicodes has decided to send me their public key. Likely, it would be something like public.pachicodes@dev.to.asc, where the .asc is an "ASCII armored" file type that is often used to store and exchange PGP keys. While the raw PGP key is a binary file, the .asc file is an ASCII representation of that binary.

Once Pachi has given me the public key, I can import the public key into my GPG key ring using gpg --import, specifying the file as an argument.

Encrypting A Message To A Friend

Now that I have my friend Pachi's public key, say that I now have a secret message (stored in for_pachi.txt) that want to send them. I want to make sure that only they can read it.

I can use their key to designate them in the --recipient flag in gpg --encrypt. Furthermore, to tell Pachi that the message is really from me by signing the encrypted file.

In full, to encrypt the for_pachi.txt file, we would do,

gpg --encrypt --sign --local-user cjtaylor1990@dev.to --recipient pachicodes@dev.to for_pachi.txt

where --sign --local-user allows gpg that I want to sign using one of my local keys, cjtaylor1990@dev.to. Again, this will produce an encrypted .gpg file.

This signing is done using the private key that you generated earlier, and GPG will once again prompt you to give a key pin. If I had given the part of my key that I can share (my public key) to Pachi earlier, GPG can compare the public key against the private key signature on the encrypted file and confirming that it was actually me who signed and encrypted it.

Assuming that Pachi has my key imported into her own GPG key ring, she can decrypt the encrypted file, see that it was from me, and what the secret message is:

Now Pachi and I have successfully exchanged public keys, and using our secret private keys, we have successfully exchanged encrypted messages back and forth to one another. Only those with access to our private keys (and key pins) could successfully sign the encrypted messages, or decrypt them to read. In this case, Pachi sees me exclaim that "We are awesome hackers!"

This idea is the heart of PGP encryption, and what makes it so powerful as a privacy and security tool. It's used in many popular privacy-focused software, such as Proton Mail and Signal as a means of strong end-to-end encryption, and has famously been used to journalistic sources and whistleblowers.

Even if anyone was able to get a hold of the traffic being sent between Pachi and myself, they would not be able to decrypt it to know what it meant, not even the service we were using to communicate!

PGP Exporting, Back-Up, And Publishing

You can export both your public and private keys as .asc files by using the gpg --export and gpg --export-secret-keys, while also specifying the key you wish to export and using the output operator (>) to specify the file name.

For cjtaylor1990@dev.to, we can export the key pair by doing:

gpg --export --armor cjtaylor1990@dev.to > public.cjtaylor1990@dev.to.asc

and,

gpg --export-secret-keys --armor cjtaylor1990@dev.to > private.cjtaylor1990@dev.to.asc

The --armor flag specifies that we want gpg to output everything armored ASCII format instead of a binary.

Now that both parts of the key pair have been exported from GPG, you can then back them up (e.g., on an encrypted drive). Backing up your keys is important, as without them, you will be able to decrypt any message intended for you nor sign any encrypted file.

Finally, you can share your PUBLIC key by uploading it to a public key server that allows other to download it and import it so that they can contact you securely.

To do this, you can use the pgp --send-keys command, specifying the key-ID (in my case, 9B7EA4B7 or the last 8 characters of my key fingerprint).

The default server is key.openpgp.org, which you can then search using your key's fingerprint.

Revoking A Compromised Key

As this whole protocol is dependent upon on each person keeping their private key uncompromised, it is important to make sure that you revoke a key that you believe to be compromised. You can likewise revoke a key if you no longer use it.

To make sure you are ready for such a scenario, you can generate a revocation certificate for your key using the gpg --gen-revoke followed by your key ID. You will then use the output operator (>) to output the data to a file, in this case revoke.cjtaylor1990@devo.to.asc. You will then be asked for more details about why you are revoking the key.

You can then keep the revoke certificate .asc file around for safe keeping (DO NOT SHARE IT) and if you find that you have to mark it as no longer a valid key, you can then import the certificate as a key into your GPG keychain. This will mark the key as revoked and no longer valid.

You can confirmed that the key was revoked using gpg --list-keys and then send the updated (revoked) public key to the public key server using gpg --send-keys.

Keeping a revoke certificate around and making sure that any compromised or unused key pairs are marked as revoked helps protect you from others reading any encrypted data with you as the recipient. Furthermore, it makes sure that others can trust that any information signed by your private key is really from you.

Deleting PGP Keys From Key Ring

If you have revoked a PGP key pair and no longer need it, you can delete it from your local key ring.

First, start by deleting the private key by using gpg --delete-secret-keys and specifying the key that you wish to delete. In this case, I am deleting the secret key associated with cjtaylor1990@dev.to that I revoked in the last section.

You are then able to delete the public key with gpg --delete-key, while specifying the key in the same fashion as you did in the previous command.

Summary And Final Thoughts

If you've been following along, you now have created your own PGP key pair (a public key and a private key) using gpg --full-generate-key. The public key can be shared with others, while the private key and your key pin should be kept secret.

With your public key, you encrypted a secret message using gpg --encrypt that only the person with your private key (the real you) can decrypt; you specified who can open it using the --recipient flag.

With gpg --decrypt and your key pin, you decrypted your secret message, confirming that it is the same one that you started with despite having been garbled and made a mess of during the encryption process.

Similarly, after importing a friends PGP public key, you were able to import it into your GPG key chain using gpg --import and then encrypt a file addressed to them using similar commands, but adding the --sign --local-user flags to sign the encrypted file with your private key and allowing your friend to know it was from you.

You learned how to export your public and private keys using gpg --export and gpg --export-secret-keys respectively as a way of backing them up. You also learned how share your public key via a PGP public key server using gpg --send-keys.

Finally, you learned how to generate a revoke certificate using gpg --gen-revoke so that, if your keys are compromised, you can invalidate them locally (by using gpg --import to import the revoke certificate) and on the PGP public key server (by using gpg --send-keys after the key has been marked invalid locally).

While this introduction does not necessarily cover all there is to know about PGP, nor does it cover specific use cases (e.g., email encryption) or how to use the GPG Tools GUI, I hope I was able to help you appreciate (or even want to use) this useful privacy tool.

I would not consider using PGP the first thing you should worry about when improving your online security posture; that would probably be to use a password manager and enabling two-factor authentication. However, I still consider it very interesting and an incredible privacy tool, with an excellent track record.

Thank you for reading this introductory tutorial on PGP encryption. I know it's been a while since I wrote anything, but this has been an interest of mine lately, and I wanted to share.

How To Maximize Your Productivity And Learning By Keeping Your Goals In Mind

Corbin Taylor — Wed, 05 Feb 2020 02:02:30 +0000

Cover photo taken in my work office at my university. Paper is Kara et al. 2016 (free at https://arxiv.org/abs/1501.06849).

I was recently involved in a brief Twitter thread with a fellow Dev.to blogger, Pachi (who you should totally check out ), and the topic of discussion was that there seems to be so much to learn. I mean, with a seemingly infinite number of tech blogs to read, YouTube tech education channels to watch, and Udemy courses to take, it can seem a bit overwhelming. This is especially true for someone new into this space, and is starting to realize just how much there is to learn. It can really make someone's head spin!

I've detailed my story in a previous blog post , and those who know me know that I'm coming into the tech field from quite the unique angle. My experience as an Astrophysicist and a PhD student has been kind of "trial by fire" for productivity and self-learning, and I hope that I can help some of you by imparting my views on the subject.

Before I begin, I will say that, in no way am I claiming that my ideas are wholly original. I've picked things up piecemeal from colleagues, self-help literature, and online sources. I am only speaking about what I've done that has proven effective for myself, and in no way am I claiming that these tips will necessarily work for everyone. I do believe that I can help at least a few people by sharing my opinion.

Note that I purposely have been vague as to when I'm talking about learning or general productivity, because in my opinion, everything can be described in terms of project management. Learning is a particular use case for what I'm about to describe where you are the project.

So, Where Do I Start?

I think one of the hardest parts of any project is figuring out where to start. After all, unless one is following some tutorial or has some outside guidance, it is often the case that they won't know where to even begin to learn about a particular subject or start a project. It's somewhat akin to the pressure one feels as they initially sit down to write and they are met with a blank, white page with a blinking cursor. We might have a vague idea in mind (e.g. "learn web development", "build an application", etc), but beyond those vague borders, we are left without a guide.

This uneasiness in almost complete freedom can lead to shut down, as the task seems just to great to even begin, or it can lead to going all directions simultaneously. Neither of these common results lead to particularly good results, as neither result in great productivity. For example, I remember when I was first started researching all the various programming languages, I thought it would be great to learn as many as I possibly could, and that would make me a great programmer. Don't get me wrong, I'm still very impressed by truly great polyglot programmers. However, you need to be able to do more than print "Hello, World!" in 20 different programming languages.

We cannot run from it. We must firmly answer the question: where do we begin?

The Recursive Productivity Function

Well, we must first actually do a bit of basic research on the domain we are trying to understand. For this, we have to ask:

What exactly do I want to do? What is my primary goal?
What does that exactly entail?
In my own words, can I break this down into individual steps?

Let's use the example of someone wanting to build a simple to-do list web app. Going through these three questions:

I want to build a to-do list web app.
I need to build a UI where a user can add entry to a list and then delete them after they are done. I also want to make sure the list saves.
Breaking down this process, I have: Build a basic skeleton of a web page, style said web document, make this web page dynamic to allow for adding and deleting entries, allow this web page to save the entries for later (even after shutdown)

Now then, based on the answer to #3, we have some more concrete steps. Obviously, this is a bit of a simplified example, but what's wonderful about this list of questions is that it can be used recursively. Each individual step that you list in question #3 could then be inserted back into this productivity function , which will produce its own list of steps. The final list of steps to be completed would then be produced by concatenating the results from each of these individual analyses.

The level to which you wish to push this is ultimately up to you and your skill level, but in my opinion it is best to have broken your original goal down to the point that the first step (or next step) seems almost trivial. By doing this, you've effectively constructed a framework to work in where there wasn't one before. You've traded in the pressure of an large-scale problem to that of making many small steps that can be overcome. It now isn't just one big goal, one big win, but many small goals, and many wins. I can guarantee that this will make you less nervous, make the process more fun, and help you fend off imposter syndrome.

Learning From Your Goals

Going back to the example of a newbie web app developer, they now know that they need to construct the basic structure of a UI. It doesn't have to look pretty, but it has to at least have the basic form. If they already know HTML or know some Web Framework (e.g. React, Angular) this may mean that they can get into this process immediately, but if they don't, then with an extra iteration of our productivity function , they know that their first step is to learn HTML.

Eventually, from a single idea (a simple to-do list application), our hypothetical newbie web app developer could eventually learn from the individual steps listed above:

Skeleton UI - HTML
Styling of UI - CSS
Making the webpage dynamic - JS
Saving the listed items - NodeJS, Express, SQL (or some other database query language, e.g. MongoDB)

By keeping their goals in mind, they have not only built the app that they had in mind, but they've also learned quite a few fundamental skills along the way.

Could they have taken a different approach, with a different tech stack? Absolutely. They are still learning the fundamentals of the development process, however, which is ultimately the most beneficial thing.

This brings us to another important point...

But What If It's Not Perfect?

I must admit, I can be a bit of a perfectionist at times, and while this has been beneficial in many ways, it can also have many detrimental side effects. One of the most relevant to this discussion, is that, very much like the pressure from a lack of concrete direction, a pressure towards perfectionism can also result in the grinding of true productivity to a halt.

If a code is never shipped, does it truly matter if its becoming increasingly more perfect?

This point is relevant to the discussion, because people will often anguish over a particular point of deciding the method by which they will reach one of their particular goals in a project. This is often times the result of, once again, too many options.

Don't Anguish Over Finding A Perfect Tech Stack

Taking the example of the web app, when determining how our hypothetical developer is going to design their to-do list program, they are likely to encounter people talking about a plethora of front-end frameworks. Should they learn Python and pick up Django or Flask? Perhaps JavaScript and use React, or maybe learn this hot new TypeScript and use Angular? What about Ruby and Rails? Of course, each framework rely on different languages and use different paradigms (client side vs. server side rendering), so perhaps you should learn all of them and then pick the perfect one. Ad infinitum...

I hope this example shows you that you should try your best to not labor over such things, especially when you are starting out. There will be time and a place to learn different frameworks for different projects. For any particular project, however, I think it is important that you try to police your thoughts before they snowball out of control. In over to overcome such issues and the anxiety that come with them.

The Minimum Viable Product

I think we can borrow a term from the software industry, and focus at first on the minimum viable product (MVP) . There is always time to make a project better after it is initially shared with the world.

For our hypothetical complete newbie web developer with the to-do list app, it is not the case that he needs any fancy framework. They could produce the front-end of an initial version of their product (their MVP) with base HTML, CSS, and JavaScript. This allows them to learn the fundamentals first, and then either come back later to refactor the project using such popular framework or start another project where they use such a framework (thus giving them an excuse to learn it as a step in the development process).

Be Content With Imperfection With Constant Improvement

I would like to also point out that the principle that you shouldn't get bogged down by the strive for perfection can also pertain to the self as well. For example, I remember many times during my early years of coding that I felt like I couldn't forget anything, and that everything I did needed be perfect. If I didn't remember something, clearly I needed to go over yet another tutorial or re-read a chapter in a book that I had just read a few weeks before. This urge to hold myself to such a unrealistic standard resulted being unproductive, increased my anxiety, and reinforced my imposter syndrome.

The pursuit of absolute perfection, either in the building of a project or in the development of the self, is a foolhardy venture. It is important that we always try to better ourselves, to learn and grow, but we must consciously realize that we will never reach some ultimate self or produce some ultimate project. We must be willing to forgive imperfections, and get fulfillment in the constant journey of improvement .

Don't overthink the process. Focus on your goals. Forgive imperfections. Finally...

Focus On Fundamentals First

One final thing I want to cover is the importance of fundamentals. What I mean by, "fundamentals," is those most components of your tech stack. In the case of our hypothetical newbie web developer, this would be HTML, CSS, and JavaScript. In the case of a data scientist, it would be Python, SQL, and basic statistics. They also include fundamental coding concepts, like the idea of a loop, a variable, an array, an object, etc.

This is analogous to the MVP concept, where you should produce the smallest, most basic, useable component first. In this case, you are the project, and those learning those basic fundamentals would be considered producing your MVP. Do those fundamentals necessarily make you job ready, or do they necessarily complete your first big project? No, but they are undoubtedly going to provide the foundation on which you continue to build upon.

These basic concepts also provide a language so that you can more readily think about the task at hand, or any future project. This makes our recursive productivity function that I introduced earlier an easier process. Our fundamentals are provide a conceptual language with which we can start to understand the vague ideas that exist at the beginning of the development process.

Conclusion

I realize that this blog post may seem a bit simplistic, or perhaps even a bit vague. In a way, that is intentional, as I think the best method by which one goes about learning and producing will be incredibly dependent on the personality of the individual in question and the problem at hand.

That being said, I do believe that the main takeaways from this post can be applied almost universally as a kind of basic problem solving toolbox:

Use a recursive productivity function to break down larger problems or goals into smaller ones. Continue until the step your first (or next) step you are to take seems almost trivial.
Stay focused on the minimum viable product as a first attempt, being weary of the tendency for perfectionism. Always work towards improvement, but realize that perfection is never truly obtainable.
Focus on the fundamentals first . Learn the basic language and concept with which you will be working. Build on that foundation, but always keep those fundamentals in view, allowing you to steel yourself against mind clutter and keep yourself grounded. They provide a basic vocabulary and grammar with which you can start to parse vague goals, improving our efficiency as problem solvers.

With that, I will end this post, and I hope this has been helpful. Depending on interest, I may write more on this subject and turn this topic into a short series.

Take care, and happy coding!

What I Accomplished In 2019 - Finding My Footing And Finding Myself

Corbin Taylor — Tue, 17 Dec 2019 03:26:47 +0000

Pictured: a part of my home office space, including some of the books I picked up throughout 2019 and a mug I bought on a family trip to Alaska.

As it is the end of 2019, and taking some inspiration from a fellow Dev user that I follow, Pachi (who you should definitely follow), I have decided to make this post about what all I accomplished this year.

While this may sound a bit self-aggrandizing, I feel that it is important to take stock of what you accomplished at the end of each year. After all, imposter syndrome is rampant in Software Development (and many technical fields in general), and allowing ourselves to take credit for our achievements helps us overcome these feelings of self-doubt. This is especially true for those who are just starting their careers, as it is very easy to feel overwhelmed and forget that even the most senior developers were newbies once (and that the same senior developers still have to use Google to debug their code).

Since my experience in coding has been so heavily intertwined with my PhD program, forgive me for some Astronomy-specific terminology. I will attempt to minimize jargon and focus mostly on the programming and development aspects.

January - March

During the American Astronomical Society 2019 Winter meeting in Seattle, I built the initial version of my production script that would allow me to build data-fittable models from my black hole calculation software. This was done with Python 3 and Bash scripting. I also got to enjoy some amazing food with some old friends and gave an awesome presentation on my research.
Built a low-resolution data-fittable model to test my production scripts. Passed all tests with only negligible interpolation errors. All testing was done with Python 3 scripts and basic statistical methods.
Allowed myself to seriously start to explore career options beyond Astrophysics and pure research.

April - June

Refactored the model production scripts to be able to scale from 100 parameter combinations to over 15,000 parameter combinations.
Dove into a colleague's massive C library and successfully wrote my own extension to it in order to interface my model with a popular X-ray analysis software. Persevered through multiple code-induced migraines and resisted (publicly) yelling about code structure.
Successfully convinced my colleagues to loan me about half of the CPUs on the Astronomy Department's private cluster. Prevented myself from getting drunk on such computational power, though still laughed maniacally.
Crunched over 10 Tb of data to produced a grid of pre-computed models. Models pass all tests with negligible interpolation error.
Started to explore Software Engineering via Codecademy and YouTube (e.g. Clement Mihailescu , Mayuko , RealToughCandy , and Chris Sean , to name a few).
Went through the Codecademy Computer Science career path to learn more about Data Structures and Algorithms. Learned that Hash Tables are over-powered and that graph search algorithms are fun.
Allowed myself shut my brain off for once (a rare thing). I enjoyed a week-long vacation with my family, taking a cruise up to Alaska for my grandparents' wedding anniversary. Got a spiffy new mug with a Moose and an amazing new hoodie.

July - September

Survived a three week work trip to the UK and Germany where I averaged 14-16 hour days, 7 days per week. This was one of the big moments that made me realize that I really wanted to pursue something new.
Gave one of the best talks I ever gave on my black hole research at the University of Southampton while in the UK. Had a senior colleague say that it was one of the best talks he had seen on the subject.
Survived German public transportation with my limited (and rusty) understanding of the language.
Started to build and test the second component of my black hole data-fittable model. All scripts passed testing.
Started to go through Codecademy's Web Development career path . Learned Javascript, including React. Re-learned HTML and CSS after a decade.
Finished a command-line tool that can help the user navigate the Washington DC subway system: WMATA Pathfinder . This was done in Python 3 using a modified depth-first-search algorithm.
Finished my personal website using HTML and CSS
Converted my academic CV into an eye-catching resume using the help of my University's career center and the book "So What Are You Going To Do With That?" .
Overcame shyness and successfully networked with people in Data Science and Software Engineering. Learned that my skills are incredibly marketable, despite being learned in a very specialized context.
Overcame my imposter syndrome and applied to a number of Software Development positions, including at Amazon Web Services
Overcame an identity crisis, deciding that Software Development was a viable career alternative for me that I would greatly enjoy.

October - December

Survived preparing application materials for research positions at Cambridge, MIT, CalTech, FlatIron, Princeton, and Southampton. Post-doctorate applications are incredibly taxing.
Participated in Hacktoberfest for the first time, successfully completing 10 pull requests and becoming a member of a Javascript ESLint plug-in project ( You-Dont-Need-Lodash-Underscore ).
Started posting here on Dev.to. Realized that the Dev community is amazing.
Successfully completed an online code assessment for a Software Development Engineer (SDE) position at Amazon Web Services.
Successfully interviewed at Amazon Web Services in Virginia. Was offered a position as an entry-level SDE. Really cool project and got along with the project manager.
Overcame another identity crises and decided that I would be happiest in Software Engineering. I decided to take the position at AWS and withdrew myself from consideration for postdoctorate research positions.
Overcame my social fear and told my advisors and colleagues about my decision to work as an SDE.
Learned more about Containers. Subscribed to Pluralsight and finished two classes on Docker by Nigel Poulton . Also went through the official Kubernetes tutorial .
Learned about MongoDB. Finished two classes on the official MongoDB University site .
Wrote an HTTP server using Node and Express . Using it as a start to a MERN-stack URL shortener project.
Finished writing the last of my black hole model codes and have produced the last of the pre-computed model grids. All tests passed. Will be pushing full beta soon and sending to collaborators.
Planned and started to execute the last of my thesis work. I will be graduating with my PhD in Summer 2020.

Conclusion

This has been quite the list to write out and I'm sure I omitted a number of victories. This process has made me realize just how much I accomplished over the last year, and has given me quite a bit more confidence in myself as a programmer and developer.

After I graduate in Summer 2020, I will be starting my job at AWS and the next chapter of my life will begin. I am nervous, but incredibly excited.

To all of you out there, especially those who are trying to get a footing in the Tech space, I hope you had a great year and that 2020 will be even better!

Accepting An Amazon Job Offer And Filling In My Skill Gaps

Corbin Taylor — Tue, 10 Dec 2019 13:11:54 +0000

Picture - Outside the cathedral at Trinity College at the University of Cambridge, Cambridge, UK. Taken by myself in Summer 2018. I just really like it.

As it has been a while since posting here on Dev, I thought I would give a bit of an update.

The Job Offer

I had alluded to getting a job offer in my last post , and I have since accepted it. After graduating from my PhD program in Summer 2020, I will be starting as a Software Development Engineer (SDE I) at Amazon Web Services. Needless to say, I am incredibly excited and proud of myself for getting the position, having not come from a traditional Computer Science background and being largely self-taught.

The final decision was not an easy one for me, as it was a final confirmation to myself that I really wanted a change in my life. I realized that I wanted something else in life other than what I initially envisioned for myself 12 years ago, and finally admitting that to myself and to my academic peers was not easy. A lot of my identity is still wrapped up in being an academic, and I'm sure that the transition will be not be overnight. However, despite this, I don't regret deciding to study Astrophysics. I think it is a wonderful field that both inspires the imagination and teaches you how to solve complex problems, and it will always be part of who I am in some way.

Containers With Docker And Kubernetes

As I am going to be working with a lot of Cloud concepts, I have started to flesh out my understanding of containers: what they are, what they are used for, and how I go about making use of them myself.

I actually started the process a bit backwards due to a lack of a firm grasp on where to start. I started with the official the Kubernetes tutorials , which by themselves are nice introductions to distributed systems and how they help better ensure service reliability.

After going through the tutorials, working through them on the Kurbernetes sandbox, the documentation then suggested looking at a few courses on third-party platforms. This led me to Pluralsight and the work of Nigel Poulton .

After a brief course overview on his Kubernetes course, I realized that I needed to start with Docker if I really wanted to understand containers. For those that are new to these technologies, think of Docker as a service that allows you to host isolated copies of a service with all the various dependencies (known as a container) on a single or multiple machines. Kubernetes is more of a way to manage these containers, balancing requests and automatically handling failure events. They are in the same technology regime, but looking at the problems from different angles. Note that it is possible to handle management across multiple machines with Docker via the use of Docker Swarm, but it seems like Kubernetes is the preferred choice in this space.

I have gone through:

The latter of the two was especially interesting, as it allowed me to use the free-tier AWS EC2 service while I was following along in the tutorials in building the container swarm. I am currently going through his Docker Deep Dive .

Assuming you can afford a Pluralsight subscription and you are interested in learning about these technologies, I would start there. Nigel is a fantastic teacher, explaining things in an entertaining and clear manner. While I have not read it, Nigel also wrote his own book on the subject that may provide a more economic way to learn it.

MongoDB

One thing that I never have understood about the culture of Astrophysics is our choice to not utilize more modern database technologies. Most of us have only seen one or two SQL queries in our entire career, and anything more complex than that is relegated to being stored as often-convoluted directories of .txt, .hdf5, .npy, and .fits files. We hope that our naming scheme is good enough for our future selves to be able to traverse the file maze 6 months down the line (and so often...it isn't).

Sure, some of this is due to the often very specific use cases, but I honestly think much of this is due to a lack of willingness to change. This has led to mountains of technical debt and the looming crisis of Big Data Astronomy.

Because of this lack of domain experience, I have taken an interest in learning about databases and query languages. I started this process a few months ago when I chose to learn SQL through Codecademy as part of their Web Development path.

Recently, I decided to learn more about NoSQL, and in particular MongoDB. I chose to focus on this technology due to its popularity and it having incredible learning resources on the official website. In particular, for those who are interested, I would highly recommend checking out the official MongoDB University , which provides Coursera-quality courses for free.

On MongoDB University, I started the Developers path and have finished:

These classes provide an excellent introduction to the query syntax and the concepts of this document-based query language. The second one is especially useful in learning about database concepts, like replication and sharding.

I think learning MongoDB while also working on learning more about Docker and Kubernetes actually makes a lot of sense. They both rely on the concept of a distributed system, and how one manages problems of service scaling and reliability, and as such the concepts learned in one will reinforce what is learned in the other.

After I have a bit more time, I will be continuing with M220JS - MongoDB for Javascript Developers .

Side Projects

As I am an incredibly busy graduate student, much of my dev learning is done during lunch or, if I have the mental capacity left, after work. My work on my side projects has been a bit slower than I would have liked it to be, but I suppose I should give myself some slack given that I just went through the existential crisis of finding (and deciding to accept) a dev job.

I am currently working on a URL shortener project (MERN stack), and have completed the skeleton of the Express middleware. I am currently using a simple Javascript object for now to represent the database (just for testing before hooking it up to a MongoDB instance), and the React front-end is still in its early stages.

Conclusion

Thanks for those that read my posts and have followed me here on Dev (over 100!). I am still trying to work out my niche on what technical things I would like to talk about, so forgive me if I mostly just do these simple personal blog posts. I try to include resources that I have found useful, as I hope that my readers will be able to take something from what I've written.

Hope you all have a great day, and happy coding!

Learning To Be A Developer And Getting My First Offer (A Personal Story)

Corbin Taylor — Thu, 07 Nov 2019 07:53:45 +0000

I recently got a notification that I have passed the interviewing process at a certain FAANG company (that shall, for now, remain nameless) for a Software Engineering position and will be soon receiving an offer. I am still a bit in shock, as it was my very first interview outside of Academia and my first white board technical interview experience.

As a way to process how I have come to this point, and as a way to perhaps give fellow coders that are looking to break into the industry, a tiny bit of insight, I wanted to write out how I've ended up here and how I've studied. I'm not trying to sell you anything and have no affiliation with any of the websites or services that I may list. I'm just telling you what I've done and experienced.

I don't claim to be an expert at this, and honestly at first there was a part of me that thought that they mistook me for someone else (BEGONE IMPOSTER SYNDROME!)

WARNING: I might have gotten creative with my analogies. Expect references to Tolkien.

A Bit About Me

As my previous posts mentioned, I do not come from the traditional Computer Science or Engineering background. My time as a PhD Astrophysics student was spent largely coding, but in a very, very different regime. For example, my primary advisor still codes in Fortran 77 and has very little understanding of OOP, but that is good enough for what we typically are doing (and he's very successful in what he does). Most of the time is spent in developing and implementing algorithms to be able to do the necessary calculations (e.g. a numerical integration of some orbits around a black hole or doing statistical analysis on telescope data), or refactoring said algorithms to be run across a computer cluster.

I'm proud of what I've done, and I've personally have learned a lot about high-performance computing. However, up until about 1 year ago, I had only cursory understanding of different programming regimes. Sure, I could implement a 4-th Order Runge-Kutta Integrator or a Markov Chain Monte Carlo, but I had only cursory understanding of what a Hash Table was. I was simultaneously over-qualified and woefully under-qualified for most Software Engineering positions.

I was always interested in computers though, and I started to realize that maybe I didn't want to be a research scientist for the rest of my life, and that I should really start to let myself explore. No harm in looking after all, so I decided to learn a bit about how the other 99% of coders actually do things.

Early Exploration

As I really didn't have any idea where to start, I decided to start looking into Quantitative Analysis and Data Science. Both I knew were good-paying careers, and they are traditionally thought to be one of the most common industry starting points with people with a PhD in Physics or Astrophysics.

For these, I used a combination of Data Camp and Kaggle . Between the two, I would lean more towards recommending Kaggle for Data Science.

I spent a quite a few months exploring both topics, and while interesting, I couldn't help but be easily distracted by other topics. As my PhD research was starting to be going towards scientific software development, refactoring my scripts into something that anyone could use, I became interested in learning more about Software Engineering and Development.

So, without much an idea as to how to start, I started where I first learned Python back in 2013: Codecademy .

While I spent a significant time exploring, I would recommend anyone looking for a change to do the same. Find something that fills you with excitement. We must permit ourselves to explore if we are to find new opportunities.

Learning Computer Science - Algorithms & Data Structures

At Codecademy, after looking through their catalog a bit, I decided to purchase a premium subscription and take their Computer Science "Career Path."

While it started off with the very basics (e.g. Python syntax), it did ramp up quite nicely. The path goes through all of the basics for algorithms and data structures, teaching you in the interactive lesson format that Codecademy is famous for.

I finally knew what a Hash Table was and I developed an adoration of Graph search algorithms. I would rate this a 9.5/10 experience, with only some minor complaints about the occasional bug that I found in the Codecademy environment.

In order to supplement this education a bit, I built a GitHub repository where I tried to implement all the major data structures and algorithms. I also started to make some very basic projects.

One project that I did that I found especially helpful in learning both the usefulness of Hash Tables and the power of Depth First Search was a command line app that recommends paths to get between two points in the Maryland-DC-Virginia subway system ( WMATA Pathfinder). It's was a fun challenge.

After learning the fundamentals, I started going through some of the Easy LeetCode questions, and I learned that I really enjoy doing these types of Technical Interview coding questions. Puzzles have always been fun for me. However, it must be noted that I did NOT go overboard on LeetCode. Take studying seriously, but don't stress yourself out over it, because burn out is a risk, and one that one should always try to avoid.

Web Development

As I thought that the Computer Science Career Path was quite good on Codecademy, I picked up their Web Development path shortly after completing the first path.

It had been years since I touched any HTML or CSS, so this process was a bit slower than the previous one. I also did not know anything about JavaScript, and was initially completely baffled by asynchronous programming. However, Codecademy was very good at explaining things, and the interactive lessons forced me to immediately apply what I'm learning.

I am currently nearing the end of this Path right now, and I'm happy to say that it was a good introduction to Full Stack Development. Their React lessons were especially nice, as well as their backend lessons.

The biggest piece of advice that I could give someone who wanted to learn Web Dev, would be to make sure you do projects outside of online tutorials. Online tutorials have a tendency to hold your hand, and while this is important in the initial exposure to the topic, I feel like I learned more about using React and API integration creating my own Weather App from scratch as compared to doing a step-by-step tutorial, even if the tutorial will likely have me building something much more complicated (e.g. Spotify playlist builder).

Hacktoberfest 2019 - Learning To Collaborate

After all of this (along with an especially busy year in my PhD studies), I was gaining some confidence in myself, though I realized I didn't have really much experience with development collaboration. While you have collaborators, for better or worse, so much of science is incredibly isolated. As such, I decided to give myself a push.

I had always been interested in the concept of participating in a hackathon, but I wasn't entirely sure about the process, as I'm shy and I am still very green. When I stumbled upon Hacktoberfest, as it was an online hackathon, I no longer had excuses. I signed up, and I got to work making pull requests.

Much of my experience with Hacktoberfest can be found in a previous post , but I wanted to still mention it, because I think it is important. Collaborations teach you a lot of things, and the sooner you can get involved in one, the better.

Building My Resume

Along with everything I've talked about, I have also been working with my campus' career center (which I would highly suggest all students take advantage of if one's available), and I had turned my massive CV that spanned a decade's of scientific research into a slim, compact resume.

This was incredibly difficult, and I would be lying if I said I didn't have many, many revisions. It is important however for you to get your resume as polished as possible.

For PhDs who are looking to change paths, a great resource for this would be "So What Are You Going to Do with That?" by Basalla and Debelius. It goes through much of the application process, and it also talks about changing your mindset when you write your resume.

The biggest piece of advice for those that are looking to change fields would be to stop thinking of yourself AS whatever you do, but instead think of yourself as a person who just so happens to do what you currently do. For academics, this can be a HUGE challenge, but it is worth the time required for the necessary self-reflection. Make sure you make those skills prominent in your resume, as those are what a potential employer will look for.

To draw upon an analogy from theater, you are a person with skills, and those skills are like the stage, the props, the actors, and the backdrop in a theatre. Those same people and items can be used to perform a multitude of plays and operas, but it is ultimately you, the playwright of your life, to decide what story they will tell.

For myself, I realized I was not an Astrophysicist, but a person with a passion for coding who chose to do Astrophysics. By making my resume about my skills, I was making a statement that I am more than whatever my past choices have been. I'm adaptable.

Applying - I Was Brave And Sleep Deprived

I had been polishing my resume for weeks, and my career counselor suggested I put out a few applications, just to get used to the process. I was nervous, but finally after a long (but successful) night of debugging the code for my PhD project, I decided that I was feeling brave enough to venture forth into the land of Indeed and LinkedIn Jobs.

After a bit of a random walk, I happened upon a listing for one particular company that I had always regarded with great respect, but one that I considered myself woefully unprepared to actually seriously apply for. If I was more conscious and had a full night's rest, I might have hesitated, but I decided to pull the trigger and apply. This was at the end of September 2019. I still remember that my hands were especially sweaty and the day after, I thought I was crazy. The tired version of myself clearly had gotten a bit too sure of itself! I was expecting my application to go into the trash immediately (and once again, another example of imposter syndrome).

I didn't think about it for a while. I continued to hone my skills a bit, do some more LeetCode, and have some fun with Hacktoberfest.

An Unexpected Journey

Very much like Gandalf showing up at the door of the hobbit, Bilbo, and tricking him into throwing a party, a couple of weeks go by and I suddenly received an email about taking an initial interview and coding assessment. I was a bit perplexed...were they positive they were emailing the right person? I decided to be brave and said yes, deciding that I would rather take the risk and go down in flames than not having tried at all.

I spent some more time on LeetCode, doing a couple of Medium questions and still failing miserably at the Hard questions. I tried my hardest to prepare, but obviously I had other obligations that kept me from optimizing my study times. I just wanted to try my best though, and that's what I aimed for.

I went through the initial assessment and interview, thought I did okay, but didn't find the optimal solutions. I had some more confidence in myself, but I wasn't expecting to advance further.

Like Bilbo however, I wasn't prepared for what was going to happen. The next thing I know, I am contacted, being invited to (figuratively) take on the dreaded On-Site Coding Interview Dragon.

I was in a bit of a daze at first...I pinched myself...I was excited...I was terrified.

(Coding) Riddles In The Dark

I had a short time to prepare, and I felt terribly, and I mean, TERRIBLY unprepared. I knew that I had to brush up on so much, and I had to really bolster my Data Structures and Algorithms. It was a bit overwhelming, and I was stressing out so much in the time leading up to the on-site, and I could only hope that I wouldn't get Smaug as an interviewer. It was certainly Out of the Frying Pan and Into the Fire.

LeetCode wasn't enough as I never was really satisfied with their explanations (if there was an explanation). I needed to really understand the these type of coding questions on a fundamental level, as that is really the only way that I knew that I would be likely to be able to apply the problem solving techniques in an interview setting.

Suddenly, in the dark depths of studying, I find my One Ring To Rule Them All: AlgoExpert . I found this platform absolutely fantastic, and I would recommend it to anyone who is trying to master Algorithms and Data Structures.

Unfortunately, AlgoExpert is not a free service, and thus may be out of reach for some people. For those who need to do this type of studying on a tight budget, there does seem to be plenty of options out there. I would suggest trying the videos put out by CS Dojo or freeCodeCamp . That being said, if you have the money, AlgoExpert is well worth the investment.

If I were to go back and give myself some advice about this pre-interview build up, I would tell myself NOT TO BE SO STRESSED OUT! I should never have let my imposter syndrome affect me like it did, making it often hard to sleep or concentrate.

Sometime stress can be the fire needed to ignite greatness in you. Just be careful as to not get burned. Take care of yourself. If you've gotten this far in the process, then you're doing something right!

The Interview

Unfortunately, I am unable to tell you details of the interview itself (I can confirm though that it did not involve slaying a dragon). It was difficult, and to tell you otherwise would be lying. That being said, for all of the cultural dread that surrounds talk of technical interviews, it wasn't AS bad as I was expecting.

The interviewers were more than happy to give me hints and clarifications, and completely understood that I was nervous. I realized that they weren't there to torture me for hours, but instead just to talk to me and to see how my thoughts came together.

Talk to your interviewers and remember to ask questions. They won't bite.

Epilogue

After the interview, I felt I did okay, but not great. I thought it was all going to be a stressful learning experience, and that would be it. I still really wanted to try to work for the company, but I thought I had fallen just short. I went back to the hotel and ate two whole pints of Ben & Jerry's ice cream, letting myself just relax and try not to agonize over how things went.

I returned back to my normal life, my regular PhD research project and my late-night forays into the land of Software Development. That is, until I get the call from the recruiter, asking if I would like to continue into the offer process.

I don't remember a whole lot about the next few minutes, only that they told me I would know more in the next few days. I then proceeded to power-walk through the Astronomy Department multiple times just to eliminate some adrenaline. I've not been that excited in a very, very long time.

I went home to celebrate, eating another pint of Ben and Jerry's (I swear I don't have a problem) and calling my family and close friends with details.

Even if it would have turned out differently, I would have still been proud of myself, because I tried my best, and I know I still have a long road ahead of me in transitioning from an Astrophysicist to a Software Engineer.

It's important to remember that every experience you have in your professional life can be useful if you allow it to be. Successes boost your confidence and act as the building blocks to the path forward. Failures are equally as important, as they teach you to be humble and be aware of the areas that you can improve upon. Always do your best, and even if you fail, you can always come back stronger.

I will say that I'm writing this without having the offer letter officially in front of me, and it's entirely possible that the company and I can't come to an agreement on terms. If so, that's fine. I still learned something, and I feel much better about myself and my future in this new career path that I've chosen to walk down.

In writing all of this, I am not in any way trying to brag. I just want my fellow rookies, and especially those that come from a non-traditional background, to know that you can succeed. Don't let your self-doubt hold you back. Don't let your stress overwhelm you. Take care of yourself and don't be afraid to go after your dreams and passions.

You are the author to your own story. Now write it.

My Hacktoberfest Experience As A Rookie

Corbin Taylor — Tue, 22 Oct 2019 06:11:05 +0000

As mentioned in my previous post, I am an Astrophysics PhD student who is trying to break into Software Engineering. I have experience with programming, but in a much different context and without much of a sense of true collaboration. Up until this October, I never participated actively in the Open Source community nor had I participated in any hackathons.

I was on a Web Dev Discord server and someone linked to the Hacktoberfest website, and at first I had no idea what it was or if I could even contribute anything worthwhile. Life is short though, and I was looking for a way to dive into development, so I signed up.

After I began, I had absolutely no idea where to begin. A lot of the problems listed on the suggested repos on the main Hacktoberfest page was a bit over my head at the time, so I had to do a bit of digging.

I quickly learned that GitHub was awash in easy beginner repositories, and I made a few PRs to a couple of them. I admit, they were low-effort, and I didn't know what I was doing at the time. These were later deemed ineligible, which I can understand why. Even if I was proud that I was able to write depth-first-search from memory in Python and JavaScript, it wasn't really contributing.

I wish I could give some good tips for beginners about where to find good problems, but really how I ended up finding a niche this Hacktoberfest was by becoming curious about the repos that were popping up in my suggestions. It was perhaps a bit inefficient, but it worked, and it allowed me to get a small sample of what is in the vast GitHub ocean.

Finally, I stumbled upon a repository for an Eslinter plugin. I had absolutely no experience with dealing with making my own linter, and it all seemed initially rather complicated.

I was just about to click away from it when I noticed an Issue that seemed just downright bizarre. I wanted to know more. I wanted to know what was going on and solve it.

Coders are ultimately problem solvers. Find the problems that you find so intriguing that you can't stop thinking about them. Let that obsession drive you.

I went to work, made a fork and started to use the tried-and-true method of solving weird bugs: liberal use of console.log().

After a couple of days, I found the issue, made the changes needed, and proudly put in a pull request. All tests passed. I had contributed!

A few days go passed, my pull request got approved, and a new version of the plugin was pushed out...but unfortunately, the change I made was incomplete. Forgetting to check one small condition resulted in the plugin throwing an error for some users. Issues were coming in and people were quite unhappy. Needless to say, my feeling of achievement quickly changed to a feeling of failure.

The maintainers were very kind and did not fault me at all. They instead encouraged me, and I decided to not only find the problem, but make sure it didn't happen again.

The bug amounted to the linter no longer being capable of handling the evaluation of higher-order functions. I fixed the bug that I induced and made a test specifically for higher-order functions. I put in another pull request and I got a lot of good feedback from the maintainers and the users. I learned from my mistake and I feel like a better programmer because of it.

It is important to remember that we all make mistakes. What is important that we are humble and we learn from them.

Since then, I've been volunteering to handle tickets and make enhancements to that repository, and have now been made a member of the development team.

My initial feeling of uncertainty being capable of contributing to Open Source was severely misguided. Just today I put in my order for my Hacktoberfest t-shirt, and have now a total of 10 PRs for October. I'm more than happy to accept free merch, and will be wearing that t-shirt proudly, but honestly I would happily do this again without any of that. It has been a blast contributing to Open Source and I absolutely will be continuing to do so into the foreseeable future.

I want to close this out by not talking about myself (as I feel like much of this post has been about me), but to address all those who are either too afraid or too uncertain in themselves to dip their toe into contributing.

Stop being hesitant and jump. Follow where your curiosity takes you. You never know where you may end up. If you make a mistake, accept it and learn from it. I can assure you that most people will be understanding. It's okay to be a rookie. Everyone was new at one time, and chances are, you are probably a lot more capable than you think you are. Every journey starts with allowing yourself to take those first few steps.

My Final Year Of Graduate School And Finding A New Path Forward

Corbin Taylor — Sun, 20 Oct 2019 05:58:47 +0000

This is my first post on Dev, so forgive me if it seems unpolished or if I somehow am missing some common conventions. Any guidance or constructive criticism is welcomed.

I am writing this post in the Fall Semester of my last year as a PhD student in Astrophysics. I have spent twelve years on my undergraduate and graduate degrees, and have years of experience analyzing data and creating computer simulations to better understand the Universe. This subject has become, like many academics I encounter, intertwined with my own personal identity.

While I am very proud of my accomplishments as a student and a scientist, I have come to an uncomfortable realization over the last year. After years of stress, late nights, and sacrificing for my scientific work, I don't know if I want to be an Astrophysicist any longer.

That is very hard to admit to myself, but I slowly am letting myself have that freedom to explore who I really want to become. My great passion for computer programming and problem solving led me to start to learn more about Software Engineering, to learn some basic Computer Science, Algorithms, and Web Development. I participated in Hacktoberfest, got involved (and am now a member of) an open source JavaScript project, and have joined the wonderful Dev community.

I feel happy. I feel a passion again that I thought I had lost.

I am still working on changing my mindset. I still feel at times like I'm a bit crazy, or that I'm not good enough to make that kind of abrupt transition from pure research into industry. I have always been one to encourage my friends to follow their happiness and to believe in themselves, and I need to learn to take my own advice.

I am writing this post to tell people like me, people who might be unhappy with their current circumstances, that it is okay. We are often much deeper and much more capable than we often think of ourselves.

Give yourself the freedom to explore your interests and passions, for it is there where you may start to construct a path forward.

I have a long path ahead of me, but I am happy to begin my journey.