Are you a junior or intermediate developer looking to become a senior?
Or are you just curious about what those senior software developers are doing behind the scenes?
What are they doing with all that time and money they earn?
The TL;DR is: a lot.
But if you want to learn more read on…
I’m Alvin. I’ve been working as software developer for over a decade in teams large and small.
I’m often asked, “what does it take to become a senior developer?”
One way is to learn to think like one, but what does that mean?
Most developers end up working in corporate environments, which pose unique challenges that are hard to show beyond cubicle walls. So, I created a software project to shed light on the kinds of decisions we make daily. The project is small enough that I could finish it during my Christmas holiday, yet complex enough to provide a sense of the various considerations developers make – from cost, to performance, to security, etc.
While juniors and intermediates tend to focus more on parts of a software system (e.g., frontend, middleware, backend, etc.), senior developers bordering on systems designers shift to looking at the overall system/architectural design. So, that’s what we’ll explore together.
For those who don’t know: a system designer (or technical architect) is usually the next step up in the career progression from senior software developer. Oftentimes, a senior dev will take on the responsibilities of a system designer, nonetheless. The lines are blurry in the software world.
So, are you ready to think like a system designer?
I won’t cram everything into this one blog post. Instead, I’ll serve them like bite-sized slices of cake. Each post will cover a specific type of system design decision senior devs typically make. Together they form a series I call:
The Toronto Fire Fan series.
Why?
Because…that’s the name of the project.
The software plots on a map: current data (at the time you’re reading this) provided by the City of Toronto to the public about active incidents to which Toronto’s fire departments are responding. They may be car accidents, medical calls, hazmat incidents, or actual fires.
Here is what the software system architecture looks like:
There are two main use cases this is meant to fulfill:
- It retrieves active incidents from the City of Toronto’s website and plots them on a map.
- It collects data (active incidents) in a database for historical analysis.
In upcoming posts, we’ll examine each part of each flow more closely and the kinds of decisions senior developers make related to each one.
Those of you working towards becoming a senior developer or architect will get a glimpse into what you might want to start thinking about as you continue your technical growth.
For everyone else: hopefully this will provide an interesting behind-the-scenes look at software development at a larger scale.
I will prepend the title of each blog post in this series with: “TFF” (for “Toronto Fire Fan”).
You can check out a working version of this software at: https://torontofirefan.com/.
Leave your questions and comments below. I’m also on Twitter (@JustSomeDev) if you want to ask your questions there.
Thank you for reading, and I’ll see you in the next one.