curve

Coding as Culture: An Anthropologist’s Road to Software Craftsmanship (1/3)

What’s going on in there?

I was writing my master’s thesis in anthropology, studying strategies for managing uncertainty in the Covid-19 epidemic, when I looked down at my computer and began to wonder – I was using this thing every day, and had done so for years, but I had little to no idea what was going on inside it. Apart from news stories about hacking and algorithms, the world behind the screen was a black box. I decided to investigate, and I found something called programming.  

“Software development has turned out to involve a combination of technical, craftlike skills along with attention to user needs and a surprisingly creative work process” 

Before I began working with the stuff inside computers, the only idea I had about this kind of work was fixing the family printer through a tedious sequence of rebooting and shuffling through solutions online. I did not like it very much. Instead, software development has turned out to involve a combination of technical, craftlike skills along with attention to user needs and a surprisingly creative work process. To me, this is what makes this field and the way we approach it at Strongminds exciting. 

Going from my first lines of code to working as a software developer has been a surprising road in many ways. The goal of this article series is to encapsulate some of the core lessons I have learned and describe what I consider essential information and skills for beginning a career in this profession.

I particularly hope that this series will be helpful to people who feel estranged from computer-related work, like I used to do, but are curious about what it might be like in reality. Some parts are mainly intended for those who have reasons to learn software development without a formal education in the field. A few people have already contacted me with questions about doing so, and the series is also informed by my attempts to wrap up my experience in conversations with them. 

 

Overview of the article series 

In this part of the series, I will address the choice of a beginner’s programming language and the overall way I have found to learn new programming concepts most efficiently.

In the second part, I will describe some lessons I have learned on how to balance details and abstractions when exploring new skills, and the importance of getting comfortable with “learning as you go”. I will also provide an overview of the central methodologies and tools that I use in my current work.

In the third part, I end the article series with an overview of the primary books and courses I have used to build my skills as a developer coming from a non-traditional educational background, and suggest some ways to find people to learn with. 

Learning as you go is an important skill in this field, and in keeping with this spirit, I will not define every technical term I use. If something sounds entirely new to you, try to decide whether you can make sense of the context around the concept or should take a few minutes to read up on it before continuing. 

 

Learning with your hands 

Picking a programming language

“Once you get comfortable with concepts like functions, collections, and control structures in one language, they will appear familiar in other languages as well”

Software is written in a variety of “languages”, so to get started, you need to learn one of these. The choice of a specific programming language is one of the things that appear to be essential when first starting out but is easily over-emphasized. There are different programming “paradigms” such as object-oriented, functional, or imperative programming, and languages intended for specific use-cases, but many of the common ones are by and large different expressions of the same ideas. Once you get comfortable with concepts like functions, collections, and control structures in one language, they will appear familiar in other languages as well. As David Farley argues when summarizing his experience as a developer in Modern Software Engineering (2022), the real tools of the trade are “the ideas that facilitate our learning and allow us to deal with the complexity of the systems that we create” (Farley 2022:38).   

For a beginner’s core language, I would focus on C# or Java, both of which are widely used general-purpose languages. “Lighter” languages like Python and JavaScript are often suggested for their lower entry barrier, but sticking with these makes it dangerously easy to skip important concepts like type safety and object-oriented design. Still, learning the fundamentals with a simpler language can work, and I had a good experience using the course Automate the Boring Stuff with Python as my introduction to programming. After this, I spent too much time clinging to Python as “my language”, as I expected other programming languages to be vastly different. If I were to start over, I would have made a faster transition to a “heavier” object-oriented language like Java or C#.

 

Code, code, code!

“You need to get the information into your fingers before you can get it into your head” 

When I first began working at Strongminds, I was handed a package of selected software development books. This included Code that fits in your Head (2021) by developer and teacher Mark Seemann, where I found many sharp observations on quality and learning in this field. For production projects, I agree with Seemann that “code is not an asset, it’s a liability” (Seemann 2021:47), but for learning, typing is essential. When following a tutorial to explore a new technology, I do not consider the tutorial done until I have written the code myself. In my experience, software development is such a practical field that you need to get the information into your fingers before you can get it into your head. Typing helps memorize keywords and terminology, as well as think through the logic of the code and its connections to other things you know. 

One of the best things to do as a new developer is to create some projects. While you are at it, make them publicly available on a website like GitLab or GitHub. When you decide on a project, do not fall into the trap of finding a tutorial that solves it for you, or letting a generative AI tool like ChatGPT handle it. Generative AI has its place in information search, but the confidence with which such tools present their solutions can trick you into not exploring the details yourself. There is no end to the “program a calculator” videos you could find online, but following any of them will teach you significantly less than going through the pain of designing the calculator yourself. Instead, use generative AI or websites like StackOverflow to find answers to specific questions when required. These are questions like “what is a lambda function?”, or “how do I position this button?”. When you have found a suitable answer, the rule of not using code that you have not typed yourself still applies. 

 

But what to code?

To provide some examples, here are the first couple of programs I made:  

  • An unstable mouse/keyboard automation script to use in my student job, which only worked on my specific screen size.  
  • A calculator where numbers above five digits would flow over the button section. My father-in-law asked if the calculator was not invented yet. 
  • A program that asked the user to enter their email address and name, and then automatically sent them a friendly email.  
  • A failed attempt at a notification system that should have informed me when tasks were available in the online portal of my student job.  
  • A coarse-grained movie recommendation system for a job application.  

Showcasing advanced algorithms or design principles with homemade projects can be difficult, and this is one of the reasons I recommend supplementing them with books and courses which include assignments that push you to address more complex concerns with your code. I recommend some resources that I have used in this way in the third part of the series. However, these assignments are likewise no replacement for the process of designing and coding your own programs on a blank slate. 

The revelations tend to come when you are out for a walk”

When you get stuck in a project, step away from the computer. The computer is the primary tool of this profession, but so far, I share the experience of Seemann who does not “recall having had a single revelation while in front of the computer” (Seemann 2021:278). The revelations tend to come when you are out for a walk. I see the ability to take time away from the machine and learn to reason about programming with pen and paper or a whiteboard as essential skills that are likely to improve the quality of your code. 

In the next part of this article series, I will turn my focus to learning processes more generally, as well as some of the core methodologies and tools that I have found to be worth exploring.

Citations 

Farley, David – Modern Software Engineering (2022, Addison-Wesley) 

Seemann, Mark – Code that fits in your Head (2021, Addison-Wesley)