Jeremiah M. Flaga — Jboy ( a software boy scout wannabe :smile: )

Email Address: flaga.jeremiah@gmail.com
Skype Id: jboyflaga
Mobile #: +63918-374-5134
Real-world Address: Kidapawan, Cotabato, Philippines


Technical Knowledge

Work Experience

I’m an Initiate; perhaps a beginning Codesmith

My learning philosophy today on software development

More Lessons Learned

Other Links

Technical Knowledge



ASP.NET MVC, ASP.NET Web API, Entity Framework, Moq, etc.

WinForms, WPF, ASP.NET Web Forms,

Web (frontend):

HTML, Bootstrap, jQuery, KnockoutJS


Java, RxJava



ORM: Entity Framework in .NET, Sugar ORM in Android

Unit Testing:

xUnit, Moq, JUnit, Mockito

Source Control:


Basic Computer Science Concepts:

Learned CS through free materials of Stanford's CS106B last 2012, through "Nand to Tetris (Part 1)" course last 2015, and through MIT OpenCourseWare 6.0001 last 2017

... also through "Computer Science Distilled" of Wladston Filho

Software Architecture or Design:

The SOLID principles

Clean Architecture model of Uncle Bob Martin

Also have knowledge on some design patterns such as Decorator, Strategy, Factory, Command

Software Development Practices:

Believes in Agile Software Development practices such as collective ownership of the codebase, code review (even pair programming or mob programming), discarding practices that does not work in a particular team and retaining those that work, and others you might want me to believe in that works in software development

Believes that TDD can greatly help us make software that is highly maintainable. (Of course that does not mean that I'm going to force it on others. :smile:)


Googling Stackoverflow :smile:

I know a little bit of Python.

I also like solving simple algorithmic problems. (I'm not an Algorithmer, so I do not have the ability to solve complex algorithmic problems.)
You can view my solutions to some simple problems here.

I read.

I had read "How to Win Friends and Influence People" in the past (year 2007 or 2008, I think), and I am rereading it sometimes to review the things I learned from it..

(I included this here because this might give me plus points... because I saw a job posting in the past where this book is a required reading if one is hired.) :grin:



Old GitHub:




Old Blogs:


Please note that I’m not a master of all the technologies/frameworks/libraries listed above. Some are listed only because I had a little bit of experience using them; and I will need time to review them if I need to use them in a project while working for you.

^ back to Contents

Work Experience

April 2012 - October 2012 (6 months)

Software Developer for web using .NET and C# at Jairosolutions (Home-based)

I experienced being in a team creating web pages using the Sitecore CMS and ASP.NET.

I experienced being in a team working as outsource developers for another company, building contest pages for www.verizoninsider.com.


Nothing extraordinary. Just finished the tasks assigned to me.

Lesson(s) Learned:

This is where I was first exposed to this idea of DDD. Our employer made us read some articles about DDD because we will be using it in an in-house project. But I was not lucky to be involved in the in-house project because the employment of three junior developers, which inlcuded me, ended after six months due to a problem unbeknownst to me.

I just saw the initial structure of the project. I saw that there was a Core module, which I now understand to be the module which holds the business rules. There was also an Infrastructure module(s), which holds the data layer, the email service, and some other parts of the system. There was no presentation layer yet during the time that I saw the project. But it has unit tests.

^ back to Contents

December 2012 – May 2016 (3 years, 5 months)

Software Developer for web using .NET and VB.NET (and C# also) at Mynd Consulting

I was part of a team that works for a client who develops apps for insurance companies. We were maintaining a web application that is used in enrollment for insurance and management of insurance records. We were using ASP.NET WebForms and the MVP design pattern to build the software. We used MS Test and Moq in writing Unit Tests. We also used KnockoutJS on some pages on the web frontend.

There was also a legacy desktop version of the application we were involved in maintaining.

There were also a few parts of the web app that were being converted to ASP.NET MVC. But I was involved in that project for about a week only.


Nothing extraordinary. Just did the tasks assigned to me.

Lesson(s) Learned:

  1. I started to understand what Object-Oriented programming is.

    (When I applied for this job, I claimed to know OOP. But I later realized that I really did not know OOP. I only knew about what a class is, what an interface is, what an abstract class is, what polymorphism is, but I did not not yet have a full understanding about their purpose.)

    This is where I started to understand the Dependency Inversion Principle, the use of the Factory design pattern, and other things.

  2. I learned that programmers at this level of their carreer needs lots of guidance/mentoring from their seniors, most especially when the project is in a complex state already, and if the seniors don't want the juniors to mess with the code. :grin:

    (When I become a senior developer someday, I intend to guide/mentor my teammates who are in the beginning years of their carreer... provided of course that they also share some of their knowledge with me. :smile:)

  3. Also, I think it will be helpful to give from time-to-time some readings or lectures about the domain of the system being maintained by the programmers, so that it will not be very hard for them to understand the parts of the codebase where knowledge of the domain is needed.

  4. This is the time where I, and my teammates, plunged into the Clean Code book because one of our team leads made us read one chapter of the book each week, and spend about an hour each week discussing that chapter.

    Unfortunately, for some reasons unknown to me, our discussions stopped after a few meetings. We did not finish the book. We only discussed up to chapter five, if I remember it correctly. And I read up to chapter 8 only of the book. :disappointed: But I learned a lot from the chapters which I read.

  5. This is where I experienced writing unit tests after-the-fact, that is, after the production code is already written. — It was hard. :smile:

    There were parts of the system that were somewhat easy to test. But there were parts that were hard to test. Those parts that were hard to tests? — those that used DateTime.Now, and static methods, and extension methods of C# (which basically are still static methods), those parts that use (what I now know as) Service Locator — I skipped testing them :smiling_imp:. Of course I first tried to look for ways on how to test those things...

    I think the time I spent writing those tests was a waste of time :grin:, partly because there were parts of the system that I skipped testing (because I did not know how to test them), and partly because I did not have the goal of using the tests to make the design of the system better at a later time, which is supposed to be the reason for writing tests for an existing software. (I did not yet know that books such as "Working Effectively with Legacy Code" existed.)

    Don't get me wrong here. I don't hate unit testing. During that time, I already have an appreciation on the benefits of having unit tests — it had been three years already since I first heard about unit testing and TDD during that time.

    I think I should have told my team leads about my opinion that writing those tests was just a waste of time. If I have told them about it, they might have explained to me why those tests should be written, and they might have helped me look for ways to write tests for the untestables that I encountered. But I was very timid during that time and was afraid to express my opinions.

    But despite that experience, I'm not against writing tests. I am even a TDD advocate today through the influence of Uncle Bob Martin. But writing tests after the production code is already written requires a somewhat different skillset than doing TDD. I was, and is still, not skillfull on writing tests after-the-fact. But I'm trying to be good at it also.

^ back to Contents

March 2-4, 2016 — Enlightenment Period

I read (and studied) Uncle Bob Martin's blog post titled "A Little Architecture".

I would say that this is the time of my enlightenment on how to structure software projects.

"Architecture is not about frameworks and databases and web servers..."

Before this time, I thought architecture is about how to combine all these frameworks together to form an application!

Windows Forms for presentation — ADO.NET for data access — SQL Server for database — ...

ASP.NET Web MVC for presentation — Entity Framework for data access — ...

Hot Towel SPA Template for frontent — ASP.NET Web API for backend — Entity Framework for data access — StructureMap as DI Container — SQL Server for database — ...

... did I place much of my time and attention in the wrong places!?... I'm not sure. Perhaps this is just part of growing up as a programmer through trial-and-error, with no one personally guiding you. :grin:

"The important decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks." --- Uncle Bob Martin

Of course I understand that the peak of an enlightenment comes from a series of little enlightenments. So even though this article of Uncle Bob is very special to me, I acknowledge that there are lots of other materials (and experiences) that helped me come into this kind of enlightenment.

^ back to Contents

October 2016 – May 2018 (1 year, 7 months)

Software Developer for mobile using Android and Java at Mynd Consulting

Involved in a team developing versions 2 and 3 of the Android app of a TV show in the US.


Nothing extraordinary. Just did the tasks assigned to me.

But this time, because I already have a better understanding of polymorphism (and its use), the SOLID principles, and other things related to software design, I tried to use these knowledge in my coding.

Lesson(s) Learned:

  1. I learned how to work on a Java platform.

    Before this job, I only knew how to do real world apps using .NET.

    Doing Android made me more confident that I can also do work on other platforms.

  2. Even though we were using RxJava in our project, which others say makes dealing with background threads much easier, there was a time where I had to deal with what they call a race condition with this threads thing while working on version 2 of the app. It was hard. The bug was intermittent. It was hard to find, partly because a large part of the project uses RxJava in a wrong way. (After I few months working on the project I discovered that when using RxJava, methods must return Observables all the way up from the data source to the presentation layer, so that they can be composed.)

    But I'm not 100% sure if the wrong way of using RxJava is truly the reason for that bug. Perhaps it was just my ignorance on how to deal with threads. Luckily, that feature was removed during the development of version 3 of the app. Yehey!

    I still have to learn more about this threads thing.

^ back to Contents

June 4, 2018 – Jun 28, 2019 (1 year, 1 month)

Software Developer for web using .NET and C# at Four13 Group (Home-based, Full-time on first three months, Part-time the following months until my resignation)

Added features and fixed bugs on an online store project which uses ASP.NET MVC

I also worked on a project which is a CMS for another online store. The project uses AngularJS (version 1) for their frontend and ASP.NET Core WebAPI for the backend.

^ back to Contents

July 1, 2019 – Present

Software Developer, using .NET, atArcanys



^ back to Contents

I'm an Initiate; perhaps a beginning Codesmith

Using Terence McGhee’s “Software Ninja Class Hierarchy”, today, I consider myself to be an Initiate, because I try to write code that is easy to read. I do that because I know that programmers spend more time reading code than writing code.

I’m not saying that I always write code that is easy to read. I still write messy code during trying times or during boring times or lazy times, with the intention of cleaning them up later of course :grin:. But I’m already aware, through experience, that code that is easy to read is valuable code. I also understand that later means never so if your organization insist that I should never write messy code, I will be happy to comply. :smile:

Also, I heard some people say that programmers sometimes sell themselves short. In relation to that, you might still forgive me if I consider myself a Level “Zero” Codesmith because I have little knowledge about TDD, the SOLID principles, Clean Architecture, and some Design Patterns. (Please note that in programming, “zero” could mean “initial” :grin:)

Caution: I claimed to know OOP when I applied for my first and second jobs. I passed the interviews during those times, of course. But a few years later, I realized that I barely knew what OOP is really all about. I came to this realization while listening to a talk of Uncle Bob Martin where he mentioned something about programmers claiming to know OOP when they do not truly know OOP. Ouch! I was that programmer. :laughing:

This kind of realization actually gives me doubt on whether I already truly understand what OO is today. But… all I can say is that today, I know that I have a better understanding of what OO truly is.

… So be cautious about me claiming to be an Initiate already. Perhaps I am still a Chump Coder, or an Expanded Chump, in which case all I can say is, “Teach me master…” :smile:

^ back to Contents

My learning philosophy today on software development

When I started coding, my focus on learning was trying to master the specifics of a programming language.

Then a few years later, my focus moved into trying to master specific frameworks and libraries.

But then I heard Uncle Bob Martin saying that software development has not changed in the last 40 years. And I heard Mattias Petter Johansson’s advise for programmers:

“… learn the stuff that doesn’t change around a lot. Learn the fundamentals that we figured out in the 70s and that have been true since. Learn programming in general. Don’t be a better Angular programmer, or even a better JavaScript programmer — just be a better programmer, period.”

So today, my focus moved into learning the basic principles of software design and methodologies, because these are the things that do not change a lot, and these things will help me make software that is highly maintainable, which many master programmers say is the primary value of software for customers (and for the programmers also).

Today, my learning philosophy is like this:

Just-in-time learning about specific languages and frameworks and libraries

Ahead-of-time learning about basic principles and practices in software development, and about programming in general

For example, there was a time when I was trying to learn AngularJS (version 1) because it was the frontend technology that is being used in my new job (just-in-time learning of specific frameworks). Then on the side, I was consuming “Refactoring: Improving the Design of Existing Code” of Martin Fowler (ahead-of-time learning of general concepts.)

I hope that kind of learning philosophy is okay with you. :smile:

^ back to Contents

More Lessons Learned

Here are other lessons I learned while working as a software developer.

We should take care of our codebase
Even if the codebase started out to be clean, it will get messy if the team working on it is not regularly checking on the code when new features are being added or when bugs are being fixed.

I believe that code review (or pair programming) and proper guidance/mentoring from seniors or from those who are already familiar with the system, even if they are not yet seniors, can help solve this problem.

I think no one wants to stay working on a messy codebase for too long. I don't want to work on a messy codebase for too long , but I can bear working on it for a long time if the team working on that codebase decides clean it up little by little everyday.

Writing unit tests after the production code is already written is hard
Through Uncle Bob's charismatic presentation of TDD in his talks, I understood the value of TDD.

So even though I had a somewhat bad experience with writing automated tests, as I stated in the "Lesson(s) Learned" section in my second job , I am not against writing automated tests. I am for it, most especially when they are written first and not last.

But if an existing codebase has no tests, and we want to write tests for it, I think we must first consider the pros and cons before continuing on that kind of endeavor. :smile:

There must be some kind of a system for asking help
Sometimes programmers get stuck with a problem that is not googleable (or sometimes they do not know what to google for), but are afraid to ask for help for some reasons only known to them. (My reason for being afraid to ask for help is because the person I will ask help from might be busy. Sometimes, I do not know who the right person to the ask. Sometimes, I'm afraid people might think I'm stupid :smile: )

I think doing pair programming from time to time can help make this awkwardness of asking questions go away.

But perhaps you know of other ways to solve this problem...

More next time...

^ back to Contents

If you have more time, here are other links which complement my résumé:

Thank you for your time!