Week 1 at Metis

Just wrapped the first week at Metis with our first project presentation and here are some of the cool stuff that I learned:

Week 1 was pretty intense already. We already have a project and coding challenges to work on. I’ll be talking about them at later posts, but here are some of the stuff I learned that stood out to me:

Pair Programming

Every day we kick off at 9am with pair programming. This is a common agile software development process where two programmers - a driver that writes code and a navigator that watches and guides along. We are randomly assigned a partner to solve various programming problems.

This technique is pretty new to me, and it’s immediately evident that it reveals things about me I’ve not seen before. I’ve had an equal chance to be the driver and the navigator and here’s what I’ve found about myself:

As the driver, I’m tempted to just strike out and flesh out my idea of the solution. So I have to stop myself when I realize I’m doing that. I’m learning to discuss and agree on the strategy with my partner first. Learning to be humble because I don’t know everything. And learning to consider other ideas.
At the same time, I find myself doing the same thing as a navigator; I wanted to dictate the direction of the program. I had to resist the urge to grab the keyboard and take over. In discussions with the driver, I have to be conscious not use words such as “easy”, “obviously”, or even “just”. Instead, I have to explain with very clear step by step instructions.

I see that when it works, both partner learned more about the problem, sees different solutions, and catches bugs that the other person may not see. It may take a bit longer, but the code is more efficient and less buggy. And I like seeing how different programmers approach the same problem.

But there’s also the off chance when a navigator becomes an assertive back-seat driver, even spelling out the code word for word. Well afterwards, I have to code my implementation and verify that, indeed, it runs faster, is less complex at, and more pythonic.

For some pair programming that I worked on, it is on my github here.

Github

I really got caught up with Git and Github in the matter of a few days. Before, I knew just enough to be able to fork and clone repos, push and pull from my repo, and keep track of branches. But now I’m able to use it effectively to collaborate with other people. I’ve come to understand how upstream and origin forks are used for, and what head/base forks in a pull requests do.

Again, here’s the link to my Github. I’ll be spending some time in the following weeks to clean everything up and annotate each repository with Readme’s.

Python

In the Python portion, I appreciated the review of some Python basics, but what was very insightful was how Python handles variable assignments. Specifically how each variable holds a reference to an object of any data type: int, boolean, list, etc. When you change a variable assigned with an immutable type, Python actually creates a new object and points the variable to it.

Below you can see how reassigning x to a different int actually changes its reference

>>> x = 3
>>> x
3
>>> id(x)
4298151992
>>> x = 42
>>> x
42
>>> id(x)
4298153032

This explains the strange behavior that I’ve seen with lists. At one point, I created a list of lists by copying a list in place. When I changed the value to part of a list, all the other lists unexpectedly change too!

>>> x = [0, 0, 0]
>>> x
[0, 0, 0]
>>> id(x)
4337580800

>>> y = [x]*3
>>> y
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]
>>> y[1][1] = 15
>>> y
[[0, 15, 0], [0, 15, 0], [0, 15, 0]]

>>> [id(element) for element in y]
[4337580800, 4337580800, 4337580800]
>>> x
[0, 15, 0]

Python lists are mutable! Which means that making a copy with y=[x]*3 actually creates copies of the reference and they’re all pointing to the same list object as x

How can I avoid this? Well there are shallow and deep copies in Python:

Deep copy: copies the contents of the variable to a new variable
- Immutable types (int, float, boolean, string, and tuples) are always deep copied
Shallow copy: copies the reference of the variable to a new variable
- Mutable types (list, dict, set) are always shallow copied

So to avoid shallow copying a list, I learned that you can use Python’s copy library to perform a deep copy. Now I can change my lists without affecting other lists. Note how the address references are different.

>>> import copy
>>> x = [0, 0, 0]
>>> id(x)
4337853216

>>> w = [copy.deepcopy(l) for l in w]
>>> [id(element) for element in w]
[4337854656, 4337854512, 4337854296]

>>> w[0][0] = 39; w[1][1] = 43; w[2][2] = 81
>>> w
[[39, 0, 0], [0, 43, 0], [0, 0, 81]]

Project 1 and Challenge

Well we already have a project due this week and a related coding challenge. I write up my project in this blog post.

-->