Jackson Bates

No Maths? No Problem!

I received a message from someone today asking more about my transition from teaching English to becoming a Software Engineer:

"I came across your profile by chance - It is very inspiring that you moved from English teaching to CS. I am curious didn't the maths part scare you? Had you done any programming before this?"

These are interesting questions because they do highlight some of my own early fears and misconceptions about becoming a professional programmer.

The short answer is that yes, the maths part did scare me - but it's because I had too narrow a definition of what maths was, and also too narrow a definition of what programming was!

As a former Arts graduate, I'm the sort of mathematician that breaks out in a cold sweat when tasked with mental arithmetic, I still can't really do long division, and anything beyond Pythagoras' Theorem or calculating the area of a circle looks like absolute wizardry to me.

But that alone is not Mathematics.

Particularly in the field of programming, thinking about problems as neatly contained micro-problems, stepping through them intentionally, and being able to think about conditions that might affect outcomes is all the practical application of mathematical thinking. This is the stuff that really matters in most day-to-day programming.

Some parts lean more on statistics. Others lean more on geometry. But fundamentally the core of programming is logic and analysis applied to solving problems. That's really just as much the domain of the Arts as it is Science. Functions in programming are affected by their arguments - 'argument' is a very artsy word, and I don't think it's application here is actually that dissimilar. Different arguments have different outcomes: as in rhetoric, so in programming.

Another misconception was about the degree to which 'Computer Science' is crucial to being an effective Software Engineer.

I'd argue that Computer Science is quite far removed from Software Engineering. CS is about the underlying theory, data structures and algorithms that enable work to be done with computers. SE is the utilisation of a range of tools and technologies into systems that solve problems. Physicists and Chemists make novel discoveries that might lead to the development of new building materials - but you don't really need to know the physical and chemical properties of a brick in order to lay one, nor to draw up the plans of the building, decide on how it will be decorated, or how that building relates to the broader infrastructure of the city in which it is constructed. Computer Science is an intrinsic part of Software Engineering, but it is not, I would argue, the most important part.

The hard part about becoming a Software Engineer was not learning to think like a Software Engineer - I think most educated people have the capacity to do it if they are inclined towards solving problems methodically. The hard part is getting others to think of you as a Software Engineer! It's harder to prove you can be an effective Engineer via regular interview processes with zero professional experience than it is to actually do it in reality.

I've spoken about my learning path and transition to professional dev work at length previously: https://youtu.be/faU2C8_hwr8.

I'd be tempted to write a fuller list of what I do think makes a good Software Engineer - but I'd wager I'm still too inexperienced to do little more than just describe the things that have helped me be successful, and I no doubt have plenty to learn about other approaches and dispositions I've not learned to value yet.

It was a good thought provoking question, though, so I'm glad to have received it!