Software development isn’t about writing code. At least not only. I would like to share my experience with the non-code-writing part
It feels people are convinced software development works more or less like this:
And it’s roughly true. It does however get interesting when one gets into details of what happens in the lower left of that picture, between the developer and the product.
And so on, and so forth.
Obviously, I would not expect a fresh software development enthusiast to know these things. After all, they have just written a premium hello world app and should not be bothered with all the ugly boring logistics crap. Some of the senior ones still don’t know this. And it still may be fine.
I’ve been doing this boring stuff ever since I started working in the industry. Although I am a dev, I have already done:
And many many more.
I kind of like this part of work, but my relationship with it is complicated. I changed a job at least once because I would have my role changed to be solely responsible for that. I promised myself to never do that stuff ever ever ever ever ever again in my life.
And I’m doing it again.
The industry Sisiphus. Source: Pixabay
You see, coding is fun, making new things is fun, solving new problems is wonderful. Dealing with a system 10+ years old is slightly less fun. Dealing with something that “works so don’t touch it” can be a traumatic experience. Imagine all the hacks and shortcuts, uncommented changes from thirty different cases merged into a single blob of semi readable code in the distributed part of a system, without guarantee that you know all the tools talking to it. Sounds horrible, but it has two main advantages:
So you end up dealing with it, maintaining, improving etc.
Now imagine this code has no tests and most people who knew how it worked have left.
It can be a difficult experience, that’s why it is so important to have a proper software development infrastructure. In many cases it can be a lifesaver. In many cases it is only devs who can provide it to themselves, sometimes because the Operations team is overloaded, sometimes because the teams have freedom to do whatever they like, sometimes because the company adopts the DevOps, or DevSecOps philosophy, whatever that means.
This leads us to what I plan to do: I would like to prepare a development/build/test/deployment environment for me to test things with and to learn. This will be a tutorialish series of posts so that you can benefit from it and point out where I am wrong.
For fun. For exercise.
What I hope to get from this:
I am a lazy person with too much on my plate, so I plan to limit it to what I can benefit from at work.
The first plans are to:
What you may expect to see:
What my expectations about you are:
See you in the next article, where I will set up Docker.
I have set up a git repository to host whatever files I may need in this tutorial. The readme also contains links to articles. The first code referes to part 0x02 and I hope to be able to release this soon. Till then, here'se a spoiler alert: you might lose some of the surprise.
