How I see software after 10 years as a software engineer 💻
Tags: software, enginery, experience, journey
Published: 2019-07-19 20:53:48

---
title: How I see software after 10 years as a software engineer 💻
description: How I see software after 10 years as a software engineer
tags: software, enginery, experience, journey
published: true
---
A quick note before I begin:

This is my first post here 😊 Also I'm not a native English language speaker, so there might be small mistakes, even if I tried my best... If you think there are mistakes, please leave a comment, so I can fix them. Thank you kindly.

I started learning software on my own around 14 years ago because I wanted to make an MMORPG game.
Fast forward 3 years, I started working on processing huge sets of data and I developed a lot of tools written in Python for fetching, transforming, validating and displaying data.
So I say I have 4 years of preparation and only 10 years of actual experience.
I don't want to mention this to brag, because I feel like a student and I still learn new things every day.
I just wanted to mention the numbers, so you can be confident that I'm qualified to say the things I'm about to say.

# Step 1 - functions

First, you begin to learn how to write software, because you have a burning desire to build something.
Maybe a game, maybe a TODO list app, maybe a Twitter alternative.

But you have no idea how to write any software, even if you might know what a "variable" means, or a "if condition", or a "for loop".
How do you tie all of that together after you write more than 100 lines of code? How do you re-use the code so that you don't have to copy&paste the same functionality? How do you read configurations from files? Where do you store your "state" after the app is closed? How do you make multiple "things" run at the same time? How do you display "the stuff" that happens inside your application?

All these little problems take so much time to learn, that you might totally forget where you started and what initiated this journey in the first place.

But if you overcome all of that, you definitely have a solid foundation and you have the potential to build any software system.

# Step 2 - libraries

You write a few projects and you start to see patterns in all of them. All the applications are doing different things, but internally, they do it in a very similar way.
These are called "design patterns" and are just templates that you can apply in similar situations.

You might hear about things like "procedural", "functional", or "OOP", but only at this point, you start to understand what they mean.

You start to feel comfortable using multiple inheritance, singletons, prototypes, decorators, iterators, event emitter, sync/ async, threads, fibers - depending on the programming language you use.

# Step 3 - systems

You learn a few programming languages. You will never be fluent in each and every one, but you can write idiomatic code.

You start to think about the architecture of multiple software systems, many of them written in different programming languages, communicating in different protocols, some of them are slow, some of them are occasionally crashing.

How can you store massive amounts of data? How can you debug live applications that push millions of lines of logs every minute?

You can orchestrate, design and maintain complex system.

# Step 4 - meta

You start to reflect on "Why do we write software?"
Software is made by people and for people...
Software as a life philosophy 🧘‍♂️

"A developer's gut feeling" might guide you to prefer some frameworks over others, for reasons that are not immediately visible for other people, because you can always find, or build alternatives.

Some examples include:
Maybe the framework, or library is too bulky for your specific usecase, so if you import this huge thing and you use 5% of it, maybe you can build your own?
Maybe the license is too restrictive and that might impact the future of the project?
Maybe you don't like that the library hosts all your data in their cloud and you want data liberation?

When you have a new project, you don't care about specific languages, or frameworks. Writing the code, or designing a system is not a problem anymore, you already know how to do that.

You want to understand "What problem is this trying to solve" first. Then you want to know "What is the most relevant way of displaying what's happening" and "How do people interact with this". Then you want to know a high level list of technical features. Only at the end you start looking at the architecture and the software frameworks.
Going from the most abstract, to the really concrete.

# Disclaimer

Don't focus too much on the order of the things I just described, this is what I think to be "the path of least resistance", but not necessarily what happens for everybody.

Each journey is unique. Also the steps have to be mixed together from time to time, especially when there's a transition.

# Conclusion

Watching yourself grow and learn a skill as interesting as Software Development is an incredible journey!

But I think a similar template applies to ANY skill out there, even if it's not related to computers.

I encourage you to do what you like and never stop learning.

What do you think? I'm curious to know your opinion!