×
A goofy growing software engineer confession

To all developers, especially lady developers, this is for you (and me) lol from me with love.

So, you know how you read about a programming language, they will tell you about the fundamentals; from what a class is; - which is a blueprint, a representation of an object depending on the domain and functional requirement, a variable; - an attribute of the object, methods/ functions being the behavior of that object or manipulation of data in that object.

They will further it down to principles of code efficiency, effectiveness, security, compliance, and standardization. They will tell you to enjoy developing the project, employ principles like abstraction and encapsulation for security, inheritance for literal spatial grouping and reuse, polymorphism also for reuse and redundancy minimization; the basic method overload and method override – ring a bell?

Do not get me wrong, you need all of this to understand the approach. I remember during my undergrad, there were these modules that even up to now I am like, well, I was going to get a distinction if you had taught me about a b c in that order. As much as I want to blame my lecturers, all the blame can be shouldered on me because if I were serious, I was supposed to have taken this current path. I remember when I got my internship, my supervisor, the one I reported to (I respect the guy upto this day), literally went like, Hazel, I need you to empty everything your lecturers taught you on building software, this is how we do it the enterprise edition, lol. I was still in a mist of confusion, on top of those deadlock-averting solutions, the FIFO strategy for memory management and resource distribution, I now have MVC to think about. Proceeding with the cloud of massive confusion, I convinced myself that Simba’s way was the best because at least – I was using C# at the time – copy-pasting the code from Contoso University reaped visual results, I had created my first WebApp with ASP.Net MVC. The challenge now spawned when I went back on the bench to finish my last year. I was still in an abyss, what I knew now was programming was hard and I doubted that I was ever to succeed and silently shied into project management.

I was well taught by a respected Professor who had done a Doctorate with MIT in complex projects. It was stressful; the documentation and research were tedious. For starters, there was the infamous agile methodology to be known to its fullness, implemented efficiently because there were forensic consultants who were sent to thoroughly inspect every process in the project lifecycle and boy was the Nigerian strict about everything. I thank God because it is just a step-by-step structure written in English unlike the squiggly lines, you needed to debug.

Fast-forward, I got a job managing software projects, reflecting, I am grateful I went under fire because it is how I manage to pass my interviews with an employer of choice. However, being real, the only way you will succeed in software leadership is when you have grasped the technical complexity thoroughly so that you do not leave things under the governance of thumb-sucking, that is a shortcut to hell. I spoke to a highly respected CTO in Zimbabwe, he put a board with concepts in 5 columns with 5 phrases on each. I gave him a fair value of what I knew which was easy for me because conceptually I was okay with most of them, I read a lot and obviously with cookies and cache, you are bound to see a thing or two about it. He opened up to me and advised me the same strategy; - technical/ software leadership will be a success if you know fundamentally everything in that domain, you narrow down to a few specific concepts you need to harness and specialize in one.

I have always wanted to be a world leader in software engineering, but I did not know where to start and how to execute it, he then said OKAY, then do code.

I was introduced to JAVA. I have a backstory about java and how I almost failed it as a core module and I did not even understand if I was coming or going, now imagine, my whole life depends on the very module, see, I did what we used to call “FLYING” at MSU. Covid had also hit so there was not much mentoring and guidance because deliverables are deliverables and having these virtual meetings sometimes wasn't effective. Frustrated and demotivated I stayed in my cocoon and started thinking of turning into a farmer (no offense), lol, at least you put in the effort and you yield results.

I tried learning from the fundamentals but was usually burnt out before I even started. That was a low point in my life. I hated every weekday; I mean morning SCRUM was just a cherry on top. Unfortunately, I am still not confident to really be inquisitive or even ask for help, I felt like I was the black sheep of the team, a loser.

One day, I recollected and started confronting myself about the uncomfortable things I did not want to face because not facing a problem was not solving anything, it was postponing it and excuses being apparatus of failures I knew I was not doing myself justice if I quit without even trying. I figured that it is never too late to start learning and there are no shortcuts no matter how late I think I am with my career. I gathered that all I had to do in the interim was stay at my workstation, try, try, and try again, so I built it bit by bit to make it comfortable to my negative subconscious side of motivation. I had a pile of tasks, I would take them one by one, and aggregate them to the most granular like how one senior developer advised, this helped me to at least register achievement frequently. “Well, I tried to build the jar, but it failed at least I have a new error to debug, let's call it an afternoon, I will come back when I am mentally ready for this stress”, I would tell myself.  

Fast-forward to today, and not much has changed, I am still a noob, but I am progressing. I love the idea of facing challenges and have learned that problems will only go away by just doing what is necessary. I have sworn to myself that anyone within my reach and vicinity should never have to stress over understanding concepts. I have decided to read about things, break them down into granules, and explain them to whoever finds my articles. This is also helpful for me because I will be internalizing the subject matter.

Recently I was reading about clean architecture and I will make it an abstract according to what I grasped. Maybe someday, somewhere, someone will use this to grasp the concept and we create a community with like people who are an ecosystem of demystifying software solutions from the bottom up, top down, and all over through it like Uncle Bob eluded. A special thanks to Matthew Renze, he is amazing at breaking down the whole perspective of clean architecture, check him out.

My closing remark will be you have to understand the components from an abstract view of the entire domain. From those components you will be able to map out which layers would you need, once that is complete like Uncle Bob said in his book, you will be able to confidently interrogate the system from top to bottom, bottom up, and through it to ensure that those fundamentals, those OOP principles, when to use records in Java and when not to, functional organization, the lifecycle of an event, queries, and commands and when to have complex functions, memory and resource optimization, data structures and algorithms,  testing the system up to automated integration test.It will give reason to those examples you see when the YouTubers and bloggers go like we have a base class called "shape" and a child class called "circle". Only then do all the above concepts and more that I have left out start to make a bit of sense.

Please note that I am still learning, so if I write something and one feels there is a better implementation, please do not hesitate to ping me,  we will explore the concepts further.