Hi, I'm

Jeremiah Flaga

I’m a software developer, with about 9 of experience, including:

  • About 8 years of experience in C# & .NET Framework (this includes some experience of using JavaScript/TypeScript for the frontend side)
  • More than one year of experience in mobile application development using Java & Android Platform
  • Some experience in refactoring code and writing tests

What can I contribute to your project?

  • Fix bugs.
  • Add new features.
  • Refactor and clean up codebase little-by-little as I work on it daily (if needed).
  • Write tests, if needed
  • If there is a need, I think I can teach younger developers the concepts of clean coding and clean architecture while working on your software, perhaps through pair programming, or through code reviews.

Skills / Technical Knowledge

.NET/.NET Core

C#, ASP.NET Web API, ASP.NET MVC, Entity Framework, Dapper, xUnit, Moq

Web (frontend)

KnockoutJS, Angular, JavaScript/TypeScript


SQL, REST, Git, Rx

Googling Stackoverflow :grin:

Software Architecture/Design

The SOLID principles

Some design Patterns

Clean Architecture of Uncle Bob Martin

Basic Computer Science Concepts:

Learned fundamentals of 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


April 2012 - October 2012 (6 months)

Software Developer (.NET)

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

Technologies used: C#, Sitecore, ASP.NET Web Forms, CSS

Nothing extraordinary. Just finished the tasks assigned to me.

This is where I was first exposed to this idea of Domain-Driven Design (DDD). I was excited with this because I have always been in search for the best way to structure software, and this DDD thing seems to offer ideas on how to do it.

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 included 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 had unit tests.

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

Software Developer (.NET)

I was part of a team working for a client who develops apps for insurance companies. We were involved in the maintenance of a web app and a desktop app used for insurance enrollment and insurance records management.

Technologies used: VB.NET, C#, ASP.NET Web Forms, KnockoutJS, jQuery, Bootstrap, Unity, Entity Framework, some ASP.NET MVC, Moq

Nothing extraordinary. Just finished the tasks assigned to me.

  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. :blush:)

  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 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.

    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 one of the reasons for writing tests for an existing software. I did not know yet that sometimes it is necessary to change production code to make them testable — something I learned later on after reading books such as "Working Effectively with Legacy Code", and after learning more about TDD.

    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. Had I 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.

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 period, I had been thinking that software architecture is about how to combine all these frameworks and libraries and tools together to form an application!

  • Windows Forms for presentation | ADO.NET for data access | SQL Server for database | etc.

  • ASP.NET Web MVC for presentation | Entity Framework for data access | etc.

  • Hot Towel SPA Template for frontend | ASP.NET Web API for backend | Entity Framework for data access | StructureMap as DI Container | SQL Server for database | etc.

... have I been putting 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.

I have always been in search for the best way to structure software systems. Now I think I already know the gist of it:

Just do your best to separate the business rules from the other parts of the software system.

Or, to use the words from the blog post “Hexagonal != Layers” by Thomas Pierrain:

divide our software in 2 distinct regions:
the inside (i.e. the business application logic)
the outside (i.e. the infrastructure code like the APIs, the SPIs, the databases, etc.).

We have to separate policy from mechanism in our software systems.

Or from the words of Uncle Bob Martin himself in his book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design”:

All software systems can be decomposed into two major elements: policy and details. The policy element embodies all the business rules and procedures. The policy is where the true value of the system lives.

The details are those things that are necessary to enable humans, other systems, and programmers to communicate with the policy, but that do not impact the behavior of the policy at all. They include IO devices, databases, web systems, servers, frameworks, communication protocols, and so forth.

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

Software Developer (Android)

Involved in developing versions 2 and 3 of an Android app for a TV show.

Technologies used: Java, Android Framework, RxJava, SugarORM

Nothing extraordinary. Just finished the tasks assigned to me.

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

  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. (Big thanks to my employer for giving me this job even though I had almost no experience with Android development.)

  2. Even though we were using RxJava in our project, which others say makes dealing with threading 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 that part of the project uses RxJava in a wrong way(?) After I few weeks/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, to avoid memory leaks and so that they can be easily 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.

June 2018 - June 2019 (1 year, 1 month)

Software Developer (.NET)

Worked on an application used for points-based rewards system for agents in a company.

Also involved in a team working on a Customer Relationship Management app for an online store. The CRM generates reports, allows searching for nearby clients, viewing quotes of clients, viewing products and number of stocks available, etc.

Technologies used: ASP.NET MVC, ASP.NET Web API, AngularJS, Entity Framework, Dapper

The first app I worked on has two ways for data access: one uses a database-first model of Entity Framework and the other one uses a code-first model of Entity Framework. This sometimes gets in the way when I'm searching for the model to use when adding features in the app. So I refactored the app so that it will only use the code-first model. Then, when the refactorings was finished, I was able to delete all of the the database-first models.

It was just a small app and not very complex, so it was doable within a short period of time. I do not advise doing that in medium sized or big apps.

I was the only one working on my first project in the company so it seemed to me that I was free to do whatever I wanted with the codebase.

There was a test module in the project, but it was empty. I thought to myself, "Maybe the original developer wanted to create tests but did not have time to create it; let me try". The codebase was not structured to be testable, so I decided to re-structure things...

... from this:         ... to this:    

... to make the code testable.

I was able to setup the tests, and then managed to create some unit tests and some acceptance tests, but I later abandoned them for some reasons...

The major reason why the tests were abandoned was this: When I started working on the project, I have this kind of mindset which says something like "I have all the time in the world to work for this project, and so I will be able to write all the tests needed". Well, I later learned that the client does not have all the time in the world to give to me. Worse, I needed to work somewhere else so I have to resign from the job.

Because of the restructuring that I did, the project now has two different structures: the original one, and the other one which makes the code easier to test. Poor guy who inherited the codebase. I hope he can be able to find which code uses which structure.

... More than a year later, when I am already working in another company, I came across these words from the book "The Mythical Man-Month" by Frederick P. Brooks:

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

... I will certainly not contend that only the architects will have good architectural ideas. Often the fresh concept does come from an implementer or from a user. However, all my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system's basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts.

I think the lesson to be learned in that is that if one decides to restructure a codebase, because he finds it hard to work with that codebase if he will not do so, he must choose a structure that is not too different from the existing one, but still makes the codebase easier to work with.

I think that changing it to a completely different structure is acceptable only if the original restructur-er will be involved in the project for a long time or until the restructuring is completed.

July 2019 - Present

Software Developer (.NET)

July 2019 - April 2020:

Member of a team working on a social networking site used by employees and clients of a company whose services involves offering coworking spaces, meeting rooms and physical offices as well as virtual offices, to people and businesses.

Technologies used: ASP.NET Web API, Entity Framework, Simple Injector

May 2020 - Jan 2021:

Our client was affected by the lockdowns, so our work with them stopped (temporarily, I hope), and our team was put on bench. I was learning Angular, Microservices in .NET, and Domain-Driven Design during this time.

February 2021 - Present:

Being involved in maintaining an app which is being used to facilitate the flow of patients in a hospital.

Technologies used: ASP.NET Web API, Angular, MongoDB, Dapper, RabbitMQ, SignalR

Software Ninja Class

I’m an Initiate; perhaps a beginner 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 during lazy times — most especially when I’m working on a legacy code base where trying to write clean code is much harder to do than when writing code from scratch — but that comes 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 insists that I should never write messy code, I will be happy to comply. It might take more time, of course.

Also, I heard some people say that programmers sometimes sell themselves short. So 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.

But Terence McGhee said that to be considered a codesmith one must already have the experience of “consistently applying these software-creation techniques successfully in real software.” So perhaps seeing my own self as a Codesmith is just wishful thinking…

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…”

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. I also 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, 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). And the maintenance phase is the most costly phase in the life of software.

“The true cost of software (80%) lies in its maintenance, not in its initial development.” — from “The Art of Clean Code” by Victor Rentea

Today, my learning philosophy is like this:

“Just-in-time learning” when learning about specific languages and frameworks and libraries

“Ahead-of-time learning” when 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 because it was the frontend framework 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.)

There was also a time when I was training on .NET Microservices and .NET Core while working for Arcanys (just-in-time learning of specific frameworks). At the same time I was reading “Patterns, Principles, and Practices of Domain-Driven Design” (ahead-of-time learning of general concepts).

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


Apart from being a software developer, I enjoy reading books (sometimes), and listening to music, and playing a little bit of piano.

Some helps I can offer you and you can offer me

Pair programming sessions

Many consultants believe that pair programming is the universal solution to any problem that a software project can have.

  • It spreads the technical skills
  • It spreads the functional knowledge
  • It builds the team
  • It’s fun

— Victor Rentea, “Brainstorming a Clean, Pragmatic Architecture”

Depending on the complexity of your codebase and of the domain for which the codebase is written, and depending on my familiarity with the technologies being used in your codebase, I might ask to have pair programming sessions with one of your programmers, for 1-3 hours per day, during my first few weeks on the job. And maybe once every two weeks after that, if still needed. This will help me become familiar with the coding styles and standards of your programming team, and of the domain of the system. This will also help in passing your team’s set of values on to me.

If I am the only programmer in the team, then I will have to trace the codebase myself to understand more about it (I’m assuming here that the codebase is small in size, and so will not be that hard to navigate, because I’m the only programmer working on it). And will just have short meetings with the domain expert when I do not understand things.

Shared set of values

high-functioning teams must have a shared set of values.

Teams that don’t enjoy a shared set of values are unstable. If each member of the team does what is right in their own eyes, without considering the values of the team; then they don’t actually comprise a team. Instead they will behave chaotically, and work at cross purposes to each other.

— Uncle Bob Martin, “Is TDD Dead? Final Thoughts about Teams.” (also in “A Spectrum of Trust”)

I would like to request for you to make me be a part of a team who tries to keep their codebase clean, and who constantly refactors the codebase to keep it clean and maintainable.

If you do not have a team like that, I would like to request to be part of a team whose team lead tries to keep the codebase clean and maintainable.

If you do not have such teams, and if your codebase is not yet too complex for me to handle, I think I will have to step up and request to take the responsibility of being a team lead — to become a foreman or an assitant coach of a team, as described by Uncle Bob Martin in his blog post “Oh Foreman, Where art Thou?”. I’m begging you to consider appointing someone who will be responsible for the state of your codebase, so that you, and your team, and me :grin:, will not suffer later on. If you cannot find anybody else, you can appoint me. I will accept the responsibility if the codebase has not yet gone over a rotting state that my current skillset can handle. I would just like you to know that I have no experience being a team lead yet, but if you appoint me I will do my best to handle that kind of role. Also, I think I will become an effective team lead only if I am involved in the coding tasks. So I need to spend half of my time coding, and half of my time reviewing code or pair programming with the team.

In case you fear that I’m an autocratic kind of person, and so is not suited for this role I’m describing…

… I read the book “How to Win Friends and Influence People” many years ago, and it had a great impact on how I view other people, so I’m not clueless about handling people so as not to hurt them very much during code review and pair programming. But I might have already forgotten many of the good ideas from that book, so I’m also open to suggestions on how to handle other programmers, if given a chance to handle them.

Also, I like many of the ideas being espoused by libertarians, who likes freedom so much. That’s another thing I can give as evidence that I don’t have an autocratic kind of attitude towards other people.

I can do compromises if needed; or turn from my initial decisions when I discover that they are wrong.

And I know of Kent Beck’s “Implementors rule”:

The Implementor’s Rule is that implementors rule. If you can’t agree and you don’t want to work together, agree a scope and whoever cares most goes and works within that scope.

I can also do with a one man team — me alone working on a small or medium sized codebase. I would just like to ask that there be some process in place where I can raise a flag if I’m stuck with a problem; and be able to ask any programmer from other teams for possible solutions of the problem.

Thank you so much :smile:

Single architectural vision

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds.

… I will certainly not contend that only the architects will have good architectural ideas. Often the fresh concept does come from an implementer or from a user. However, all my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system’s basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts.

Frederick P. Brooks, Jr., “The Mythical Man-Month”, chapter 4

Fred Brooks, it seems to me, is suggesting that it’s best if a codebase follows a single structure or architecture.

I would like to request that…

If the architecture of the codebase I’ll be working on is obvious on first look, and if it was already decided by the team to keep following that architecture, then no request coming from me regarding this.

If the architecture of the codebase I’ll be working on is not obvious on first look (because there might be two or three competing architectures), I would like to request for the team lead of software development to explain his architectural vision for the codebase. By “architectural vision” I mean the direction he wants the codebase to follow moving forward. This will help me see where the codebase is supposed to be going, and to have good knowledge on how I should write my code as to not deviate from his architectural vision.

I would like to note that when I use the words “team lead”, what’s in my mind is someone who is also working on the project hands-on, because in that case the team lead truly knows the codebase and its problems, and so it will be hard to argue against his architectural vision. If he is not hands-on, but his architectural vision still makes sense, then I will still respect his architectural vision.

If the codebase does not have an architecture (it’s a mess because there are hundreds of competing architectural ideas within the same codebase), and no architectural vision is in place, then I would suggest that someone or sometwo be assigned to look for an architectural vision that will be followed from a set time in the future and forwards. If I am choosen to be the one who will set the architectural vision for the codebase, I would like to ask the client (or maybe the non-technical coach) that it be made clear to the team why a single architectural idea is needed — that is, to make the codebase easier to manage or maintain* in the long run — so that they will not rebel against me :smile:, and so that my will to design will be reinforced (it needs reinforcement because I am leaning towards the introvert side of the Introvert-Extrovert spectrum).

Depending on the complexity and size of your codebase, it might take a few months of working on it (because I’m not a genius) before I can find an architectural vision which matches with the current state of the codebase — that is, an architectural vision that will not require a big overhaul of the codebase, but still makes it maintainable.

Also, because I know that someone out there is better than me at doing things, I am ready to step down from the position of being in charge of the codebase if someone more competent than me is needed to take charge of it.

Also, if I see someone in the team who has design sense, I will try to make him a co-coach and give some of the responsibilities that I have, so that someday I can leave the project without worrying that it will go to a mess. Or, if I will not leave, at least I have contributed to the carrer of someone who might become a programming coach someday — because I think we really need lots of programming coaches these days. Even I need a programming coach (I might be making mistakes which I do not know are mistakes). I hope I can find a coach someday.

* “The true cost (80%) of software lies in its maintenance, not in its initial development.” - time 03:17 of “The Art of Clean Code” by Victor Rentea

Please note that if there is a plan to scrap or replace the codebase after a year or two, there might be no need for this architectural vision thing. It is most needed when the system is expected to be maintained for 10 or 20 years more, with lots of requirement changes during those years.


go to Anti-résumé