The Joy and Frustration of Software Engineering
– Ada Lovelace – 1815-1852, First software programmer and mathematician
Being motivated as a software developer is directly related to the motivation behind choosing this profession. Be genuinely interested in improving our programming skills, be precise and write valid bug-free code that minimizes the computational power required to solve the problem. Keep searching for the holy grail of the best framework, best language, best IDE that facilitate our task, who loves VIM who loves Intellj Idea, who loves SlickEdit is all at the end a matter of taste and speed of write code execution, fix bugs and submit to the central repository in a DevOps fashion.
Games as inspiration to become a programmer
My passion came from early age exposure to Nintendo games like Mario Bros written by Shigeru Miyamoto and later on playing Doom written by John Carmack of IdSoftware. As a teenager, they were like inspirational athletes to me. I was fascinated by the beauty of those games.
Then I discovered that this was the work of programming, a new profession known only to a few people. So I decided to be one as well one day. I initially studied software as self-taught Basic programming during my primary school when I found a sample code on a Music book in MS-DOS. The code just produced a short and long beep like Morse code, but for me, this was just great! I then studied C/ C++ at the Industrial Technical Institute and later learned Java and Scala at the University of Turin.
Challenges in software engineering
Write software is quite challenging, it requires great effort, and some bugs are tough to find and fix. Finding a bug later in the project would prove to be very expensive and require much effort than if the same bug was found early on during the project. This fact led to the Agile movement and the Scrum / Extreme Programming. Release code fast daily so bugs can be found as early as possible.
We fail in order to succeed because software development of medium to large projects involves writing different dependency modules and microservice, a lot of architectural design and sometimes trying a lot of incorrect ideas, assertions, pattern, and architectural designs, etc. in order to find the one that will work. Unless previous direct programming experience already teaches you what works and what does not. Trying to deal with all this is quite frankly frustrating. I think the biggest reason many newbie coders abandon software development is that they get frustrated.
After all, who wants to pursue something that is constantly reminding you of how much you don't know and what you are doing wrong? One of the hardest lessons the new coder needs to learn is that frustration is not only something to overcome but something that needs to be embraced. Software development, much like a video game or a Role-Playing Character (RPC), is about levels and trying to get to the next one (level up). Another source of frustration is the introduction in the market of new technology, new paradigms, new languages, new trends and ways of deployments like DevOps. This requires a new skill set and a new mindset that developers need to understand and apply, putting developers on the pressure to keep learning all the time, otherwise their knowledge might be not usable anymore on future projects, where a new stack of technology is employed.
How to test code more efficiently
If you are doing development right, you not only know what level you are at but what it looks like to get to the next level. If you are not frustrated with how you are doing in tech, it might be because you are not learning anything. Those of us who had done coding before always remember what it was like when we were starting and how things that are obvious to us now we're so much more difficult back then.
Two excellent websites that gamify code training and learning new techniques that I used sometimes, and found it quite a fun experience, are:
Two versions of the same logic have a different value based on readability, maintainability, security and performance. Ultimately a code should be secure, have high performance, be easy to read and to test. Tests should also be automated; we have two kinds of test: Unit Test and Integration Test.
Software Engineering: The Good Parts
Some of you may have noticed I took the title from the famous book “JavaScript: The Good Parts” of Douglas Crockford. It was one of my favourite books when I started to learn Javascript for a big web mobile project.
In Software Engineering like in Javascript language, we have parts to use and be happy about it, the parts to discard that we should avoid or change, and the parts to beware of that also exist.
Your job is never boring
You need a solid foundation to build on top, that can come from University or personal programming experience and useful programming book reference. Up upon that, then every day is different (and for certain types of people that is a blessing). Is one of the few jobs where tasks are usually never dull and repetitive (and if you find a tedious, repetitive task, chances are high you can potentially automate it with some piece of code). Every day you’ll be presented with new challenges. You’re an engineer working on potentially very complex problems. You need to know how to figure things out, and if you don’t, you need to learn it on the job.
Remote working, even for just a few days a week, makes for a good work/life balance. It’s not allowed in all the environments, but remote working is a perk that’s very well suited to software development. If you are one of those developers that want a 100% remote job, then you are given the choice of living anywhere you want, a decent internet connection and also VPN allow working from home as you were in the office.
It’s not painting or playing a musical instrument, but programming is also a highly creative profession backed by science. Any time you set out to write a program, you’re creating something new. Every time you write a new program, you learn something new and improve your skills.
There is pride to make software bug free and create something that runs and outlasts the age of humans like software that goes to Moon or software that runs on servers and keeps running for years.
Programming is social and future proof
Even if one might spend 10 hours a day sitting alone with a computer, saying programming is social is entirely right. We use software built by people, people wrote the manuals and guides to use that software, we rely on Open Source software, interact with people on forums to discuss and learn more about programming, and finally, we make the software for people. You work with a team that might be distributed or local to your office. You have stakeholders; people are waiting for your fixes. Programmers like to go to conferences, the bravest even speak at them, and we like to rant, comment or share things on Twitter. We start projects on GitHub, open issues, submit a pull request to improve the work of someone else.
Software Engineering is a well-paid job. It takes a long time to be proficient, comparable to mastering a new language at it requires thousands of hours practising and learning all the nuances of words and grammar structures and slight differences. Those require a significant effort but over time can give you new “superpowers” like being able to speak a new language allows you to communicate with people from different nations.
Software Engineering is future proof; many jobs will disappear as they get outdated or not required anymore due to Machine Learning and Software automation heuristics. But it is improbable that machines will be able to write code themselves as good as humans still for a long time.