okekechimezieglory Goto Github PK

🤵 Software engineer with +7 years of experience (first job in ~2012), check out my LinkedIn or CV or [Portfolio] for more professional information.

I'm a persistent hardhead (I'll try again and again, until I succeed!), natural saver, proactive, challenge lover, bug hunter, keyboard banger, father of many like father Abraham (🔥🧊), pencil and paint artist, lover of poetry and spoken word, a poet as well as Christ is one. 🍨

These little pieces of text have the power to transcend my own existence 😵

💼 Work: formerly Software Engineer at Lloydant

🛠 Certification: ALX-T Full Stack Developer Udacity Nanodegree Program

🛠 Skills: My key languages are C#, Python and PHP. On a daily basis I architect with web Apps, REST APIs, tests, general optimizations and learning. About storage/messages, I'm normally using Microsoft SQL Server, PostgreSQL, MySQL, SQLite.

At the moment I'm trying GraphQL with ASP.net Core, and already testing out Angular, NextJs and React.

⌛ Past: VB.net, Laravel, a bit of Java, jQuery, VueJS and dead tech.

• Personal rule of thumb: Every now and then we're surrounded by new ideas and technologies, which means that everything we're building is already a kind of legacy, which will be dumped (errr transformed) a couple of years ahead.

  I think it's part of our job to make the transition easier, by minimizing the amount of code, complex architectures and customizations to the minimum. Choosing long-standing libraries and avoiding being an innovator/early-adopter might help.

• Code fragmentation: The less code the better! Naturally the same should apply to the number of files, classes, tools, services, etc.

  Simple and small functions/classes (implicitly fragmented across several files) are easier to test, reuse, understand and difficult to break. I can't disagree with that! But in my experience debugging/reading such code highly increases my cognitive load, I feel like reading a book where each paragraph sends me to a random page, with no context, and switching between these pages is painful (unless when I'm the creator 😁).

  This way I generally try to avoid fragmenting too much the code and also creating too many abstractions... Basically, I think that a god method/class is horrible, but the inverse is not less cruel.

• Micro-optimizations: I like them haha! But it's not fruitful to spend much time nitpicking (micro-optimizations) and sharpening your knife (overengineering) for a war that may never come, better to spend some time on macro-optimizations using a profiler ¯\(ツ)/¯

• Code complexity: Everything in life needs equilibrium, especially when a piece of code becomes so complex, that even its creator can't fully understand it without reading the code throughly. As there's no rules about it (what's simple for you, might be complex for me), I think it's enough to align the complexity with your team.

• Dependencies: I'm against depending too much on specific features from closed source products/vendors, everything should be replaceable. On the other hand, I fully support using popular open-source projects, as you get support, documentation, testers and upgrades for free.

  After having some experience modernizing large legacy code bases, I'd say it's much better to use ready packages than hand-made code, even if you can do a better job.

  p.s.: I'm currently involved with an Open source project where I am the lead for the testers testing the Backend API's(Python - Flask) and as well the frontend scripts(ReactJS)

• Slow vs fast languages: I enjoy using the fastest language available, but in the end processing speed is overrated. For general applications, what really matter is having an effective data transfer/structure, as the key to performance is avoiding/delaying/throttling the resource usage.

• Coding patterns: I see coding as a kind of art, so I'm not a big fan of materials spitting coding rules. Some people end up using those as a kind of "horse eye patch", which limits their alternatives, while the truth is that a problem might have N different (and equally great) solutions. But yeah, things are easier when everybody speaks the same language :)

• Reinventing the wheel: Traditional jobs, require standard approaches. Despite that, I think reinventing the wheel is the best way to evolve something, it gives us freedom to filter out bad decisions and merge in the good ones, that's how disruptive tools/approaches are born.

• My first programming language was VB.net and I can still write it because it was a breeze for me or as though I was communicating in the english language.

• My foods especially "Rice" used to get burnt during my early days of programming in school.

• I like to teach what I know and especially the underlying workings so you can figure stuffs going forward and not depend on me.

• Inasmuch I like women, I am faithful and not a player.

• for the record, I think and dispel insights that are revealational and cause shifts with help from the Holy Spirit :)

• I tried to build windows applications that fits the screen when the maximize button is clicked and I was successful at that after countless efforts, I was wondering while about 97% of people/companies do not apply it in their applications except Microsoft and a few, wondering if it was only known by them as other people/companies couldn't figure out how to achieve that little thing.

• whenever windows application were deployed, it doesn't work smoothly on the deployed system except it has visual studio installed, that was a problem also and none in my entire school had a solution to that, I was able to get past that hurdle and I felt good about it.

• Because of the struggle in figuring things out on my own, led me to shifting from the .net to php as the community is large and you can easily find solutions to your problems or open-sourced apps as explained by a friend and the singing of their praises or maybe blowing their trumpets but I am back to .NET again(EVERYTHING dotnet😘😊), not dropping it.