Seas get degrees
[My dream job, as a kid, was to be a teacher. Turns out it's a pretty crummy job in reality. But this desire to share and learn has not left me. Fish University is a series I intend to use to share some of the things I've learned in my past two years as a professional coder, and hopefully give people insight that extends past coding. If you've ever wanted to give basic coding a whirl, stay a while and listen! Each entry will be split into two parts: Theory and Practice. Theory never involves actual code, so if you're not actually interested in coding you can stick to that!]
Let’s start the first lesson with a more philosophical topic than the norm. Coding has a lot of unique issues that arise as projects and teams grow in scope. Setting expectations right away may help.
I can trace back most issues I've had to two common challenges. The first is that work we do is a lot more permanent than you'd think at first. More and more people use the code you write. Additional code is added on top of what you wrote over time. Your code has a legacy, and legacy code is dangerous. It takes a life of its own which nobody truly masters. This problem is never truly solved. We can all do our part to not encourage it. Writing for the long term implies taking the time to clean up your code and add test coverage. Even when you'd much rather be working on new features right away.
The second challenge comes from working as a group. Other contributors should be able to jump in and help too. Your work must be easy to grok. Documentation is key, and so are regular communication and feedback. It's no use trying to shoulder all the work by yourself. Your coworkers will have trouble keeping up, and you'll be at the risk of burning out.
In my two years of work since graduating from University, my personality and values were tested on a regular basis. Nobody's against virtue. And yet conflict is easy to cause and hard to avoid. Here are some things I found absolutely crucial so far.
There’s nothing worse than wasting a lot of time on a solution that is way too complicated for its own good, or that does not really solve the initial problem. Happened to me more times than I’d like to admit. You should be able to explain to someone else the problem you’re solving, how you’re solving it, and the pros/cons of your solution. It’s worth the mental exercise of reconsidering your solution if you’re unable to do it in the middle of your work.
You’re going to make mistakes. There’s no getting around it. Nobody truly masters the entirety of coding, and you’re going to find people who are more knowledgeable about something than you. Listen to them. Don’t take it personally, and use these moments as an opportunity to improve yourself. There’s always room to grow.
There’s a fine line to walk. In all likelihood, you will not be the first person to run into an issue. At the same time, your coworkers have their own issues on their plate. Everyone is on the same boat! Just make sure to show that you put in some research work yourself before asking questions.
I call the inability to do this the intern problem. It took me months and months to unlearn this reflex to rush things. The feeling that you need to start working on solutions as quickly as possible… It can be very dangerous. The roots of an idea, once planted, are hard to get rid of. Make sure the expectations of your work are well defined before you ever let that happen.
This reality of coding is hard to portray at school. Homework is built around short-term objectives and easily discarded code. Teachers have way too many students to give constant feedback, and group projects often end up with one person carrying the team.
It’s a tricky problem to work around. When we get around to tougher practice examples down the line, I think it would be a good idea to set up a peer review system so that you can train alongside someone else.
Here are some questions to help you get a feel for things. There is no wrong answer here, this is just an opportunity to get into the mindset of situations that may arise at work. Just think about these situations and how you would handle them.
For this week’s practice, we will give coding a try with Python and your operating system’s terminal.
Python is perfect for beginners for a couple of reasons. It works on any operating system and the syntax is very close to spoken language. We’ll go into the theory of different coding languages at a later time.
Start by installing Python 3 on the official website. Now we’re ready to write some code!
Writing “hello world” is a classic first step into the world of a new language. Since it is super simple in Python, let’s do it directly in a terminal!
Start by opening a terminal window -- bash on Linux, PowerShell or cmd on Windows.
Write python and press enter to start a new Python session! Then write print (“hello world!”) to write hello world to the terminal. This should look like this:
Congratulations, you’ve coded!
Now, the usual goal behind coding is to automate tasks that we humans are too lazy to accomplish ourselves – and we’re clearly losing out to our PC here!
Writing a command or two inside of a terminal is all well and good, but ultimately, we want to have a file that we can run.
First, we’ll want a text editor. Here are a couple of personal recommendations if you don’t have one of choice yourself.
Visual Studio Code: A free multiplatform editor by Microsoft. There are a ton of extensions out there with added support for different coding languages. (I will use this editor for Python examples)
Notepad++: An open-source editor for Windows. Like notepad but with extra steps. Basic, sturdy, does the job really well.
PyCharm Community Edition: The free version of a multiplatform editor by JetBrains. Specialized for Python and has tons and tons of tailored features, but it is a bit harsher on the hardware.
Now that this is done, let’s create a new python program! Let’s start by simply creating a file that contains our hello-world message. Python files have a ‘.py’ extension. Create a file named ‘myfirstprogram.py’, then simply paste the python command we talked about earlier. As long as you're in the correct folder, you can now run your file directly from a terminal with “python myfirstprogram.py”.
Some characters have special meanings that are unlocked with the power of a backslash. The letter n, for example, becomes the all-powerful new-line (\n)! Try it out in the middle of hello-world and you’ll see what that means.
If you wish to print a backslash, you need to escape the backslash by adding – another backslash! Try adding another print to the file that writes down two backslashes in a row. These things stack up quite quickly, don’t they?
Now that we know how to run code from a file, it’s time to make our computer do some actual work for us!
Download the files over on my GitHub page and check out mysecondprogram.py to learn about loops and conditions! Start by running the script, and then dive into it to see the nitty-gritty and get prepared for your homework. Feel free to make any of the modifications you want with the code (outside of utilities.py).
You’ll see there is an empty method at the end of the second program. Your goal is to add code in that method that does this for all numbers between 0 and a chosen number (between 2 and 100):
The result should look like:
And that’s it for our first lesson. Thanks so much for sticking with me until the end! When we next meet, we’ll talk about how computer babies are made.