Learning to not fear the unknown

This past week I've been fascinated to watch my students work in each other's repos. They have very different ways of approaching code they didn't write.  For the most part it goes well, but some are more successful, and it's useful to consider why that might be so.

For example, I've been most impressed with the students who have tried working on a lanugage that was completely new to them, or at least one that they haven't touched in a long time.  It's easy to play it safe, and only work in your comfort zone.  However, a big part of being a student (and a junior developer) is to avoid getting stuck in one particular tech stack too early.  I think the goal should be to become a generalist programmer: someone who can work on a problem in lots of different languages and technologies.  Doing so positions you to join a lot more teams and companies.  If all you know how to do is work in language X, you miss out on many opportutnies.

Let me show you some examples of what I mean, and then try to draw some conclusions.

Andrew makes a great point about how tooling vs. the language can be the hardest part, as he works on a project in Java:

Most problem didn't come from the code itself, but from working with maven. I couldn't find the jssg-0.0.1-SNAPSHOT.jar mentioned inside the project README. So I came back to the issue and asked Trang for clarification. I had never worked with a Java project so I didn't know I had to run mvn install, which was just like npm install for installing dependencies. A reminder of what seems to be pretty obvious for some developers, but is obscure for others that have different programming backgrounds.

Trang writes about the importance of working with the community to help you overcome problems when using a new language:

All Javascript repositories were picked and only C# left. And I had no other choices…This is the first time I have seen C# codes on Diana’s repo. I was having difficulties with running the project at first but thanks to Diana’s help. I was able to get it up and running. I just have 01 day left and I completed it in 02 hours and a half. I did this by asking my friend who is a newbie with C#. He helped me to install the library, get familiar with Visual Studio Code’s tools and syntaxes. All of the codes and the approaches were written by myself.

Joshua talks about how reading someone else's code enables us to go faster, since many problems are already solved, if we can extend existing solutions:

It was pretty easy to get back into JavaScript, although I never made many command line programs using JavaScript. I mainly only had used JavaScript for web development projects. So it was cool to see how Ritik did this using the Commander package.

Diana stepped outside her comfort zone in order to work with JS as well, and while it wasn't easy at first, it was doable in the end.  She writes:

When I first started working on the dodo-ssg, I felt like my brain was melting. I think that it had to do with the fact that in the last couple of months, I have been mostly working with C#, Python, and a bit of Java, which have a completely different feel compared to JavaScript. It took me a while until everything clicked in 💡. When I was looking at a variable named "fs" and it took me a while to unfreeze and figure out that that was to store a file system😳 Moreover, I remembered that when checking if a variable is of type string, we have to also check whether is it is an instance of a String object, because JavaScript is weird🙈... This time it took me a while to actually sit down and start working on this contribution(🐌!!) because I didn't know what solution to come up with. I learned that it is better to start working on the problem as soon as possible even if it just means setting everything up for the project or coding the first step of a solution. Because the more you think, the more fears come into your mind and it just becomes harder and harder to get started. In reality, most of the time it is easier than you think😅.

Similarly, Anatoliy got thrust deep into the world of Swift development, which was painful at first, but rewarding once completed:

...this time I decided to change lab partner to learn new technologies and get out of my comfort zone(JavaScript). I found someone who worked on Swift and thought it would be a great experience...Here you can see how many open tabs I had to find info on how to work with @Arguments@Options@Flags for command-line applications in Swift...Sometimes, even google didn’t understand my querries...Overall, I liked this lab, I felt so good after solving the problem, maybe not even ideally, and now I want to try something new more cause I got a lot of experience by working on this lab.

I wanted to end with Amasia, who took it upon herself to support one of her classmates who hadn't had a contribution yet.  Doing so required her to learn and work with Rust, which was totally new, but also something she found she could learn, and actually leverage her existing C/C++ knowledge:

When I started reading the code, I realized that Rust looked like a grocery store receipt... none of the syntax looked to be a full word. I was shocked at how much I was able to pick up though. I was able to read the implementation very easily with keywords such as fn, or enums - all familiar... The funniest thing about this week's contribution was that I was able to understand the code, and knew what I needed to do - but I had no idea how to write it. The first thing I asked Jerry to help me learn Rust was how to print out variables. The syntax is very similar to C++: println!("{:?}", variable_you_want_to_print) Next, I Googled how to parse JSON files in Rust. Surprisingly, there was a "crate" that would completely take care of this using key and value pairs. I quickly realized how similar Rust syntax was to C/C++, and was able to understand how to read the config file.

She ends with a great discussion about the aspects of Rust she learned in the process, culminating in a succesfully merged PR.

Reading through these posts, I'm struck by a number of common themes:

• learning takes time.  If we don't give ourselves enough time to succeed, it's hard to do all the learning necessary to get there.  "I tried for an hour and can't do anything!" just means you need to spend more time.
• we're able to do more than what we know when we start.  Connected to the first point, our ability to work on technology and code we don't know is much greater than we realize.  We convince ourselves that we're not good enough, and then do our best to make it come true by not trying.  Breaking this self-fulfilling prophecy takes courage.
• it's not going to feel good when you're going through it.  No one likes being in a situation where they can't make progress.  It's painful to have your usual pace of work reduced to slow motion by a lack of knowledge about the language.  However, the thrill of getting it to work in the end id seductive. Remember, being a student is about learning, so don't feel badly that you're spending time learning something new.
• asking questions accelerates our progress.  If we try to do everything on our own, we don't go very fast, or very far.  It seems like a bad idea to expose our lack of knowledge to others, but that's exactly how we get things done if we can translate this into a good question.
• programming languages share more than you think they will.  Once you've learned a few programming languages, you start to see the overlap, the shared influence, and the many commonalities.  Maybe you haven't ever touched Swift, C#, or Rust, but you'll be amazed at how all that C/C++/Java/JS/etc will help you to pick it up much faster than you think.

I hope that the examples above will inspire more students to take risks and experiment with sending PRs to projects in languages they don't know.