Jeremiah Flaga My thoughts and experiences on programming, life, atbp.

I get it already...


Each software development team is different from the other. What works in one team might not work in another.

Each team must agree to some set of values when working on a project.

A team must make a new participant agree to their set of values.

A new member of a team must agree with the team’s existing set of values.

I’m a TDD fan. But many others are not.

Rethinking the use of TDD


This is what Jimmy Bogard said in the conclusion of his talk, “Crafting Wicked Domain Models” (NDC 2012):

DDD is all about building domain models that encapsulate the behavior.

So I’m not hiding behavior. I’m just saying it’s up to the domain model itself to perform all these operations itself, and its gonna take care of its own. It defines its boundaries — it does not let anyone do whatever it wants. It wraps up everyting nicely in a nice neat bowl.

This is how I was able to eliminate bugs in our application a lot more easily than just writing a whole bunch of tests. Writing a bunch of tests still requires me to know how to write those tests, but in this case the domain model is offering me the right path.

That last sentence makes me rethink the use of TDD in creating (almost) bug-free software.

TDD might help in teaching about design, even without a teacher


In his talk, “The Deep Synergy Between Testability and Good Design (NDC 2010)”, Michael Feathers said these:

“If your code is not testable, then it is not a good design.”

“In general, every time you encounter a testability problem, there is an underlying design problem.”

“If you’re finding trouble testing things, reconsider your design and end up with something better.”

Perhaps writing tests can be used in teaching design when no teacher is available to teach design!?

"They will pardon my english"



I’m going public…

I’m not an English teacher. And English is not my native language.

They will “pardon my english”… I hope… :smile:

Fernando Cejas - Be prepare for change image

What is the most basic rule when writing code?

Do you like simple rules?

Simple rules

I like simple, but/and/yet all-encompassing rules (partly because I’m not very good at remembering lots of things :smile: ):

You can start anywhere.

“If it sounds good, it is good.” — Duke Ellington

“Everything should be as simple as possible, but not simpler.” — Albert Einstein

If it is hard, it must be wrong.

Two Dead People


Any fool can criticize, condemn, and complain — and most fools do.

But it takes character and self-control to be understanding and forgiving.

I got that from the book “How to Win Friends and Influence People”. (This book is very dear to me because it helped me change the way I view other people — it changed, to a large degree, my cynicism.)

In the same chapter where I got that quote, the book says this:

“God Himself, sir, does not propose to judge man until the end of his days.”


Does that mean it is okay to judge people when they are already dead?

Okay… Let’s do some judging of some dead people!

"Craftsmen can learn from apprentices"


When I was young (about 16 or 17 years old), I remember writing in my notebook something that goes like this:

(I was aspiring to become a pastor during that time)

When you are already a pastor, and you need to make some major decisions, make sure to also consult people who are much younger than you, because they might have some ideas that you and the older people failed to consider.

Two witnesses against the 'Copenhagen Interpretation' thing


(TLDR: This is just my story of how I got more convinced that this “Copenhagen Interpretation” thing, this idea of “something being in two different states at the same time”, is not right. If you do not like stories, you can stop reading at this point. :smile: )

Copenhagen Interpretation?

Big words!

What is that?

Quality, not quantity, might be the answer


During the panel discussion at the DevCon Davao 2017 last October 7, the panelists talked about the number of programmers needed by the industry versus the number of programmers being produced by the academia.

One of the panelists said that the industry needs about 5000 programmers every year (if I am not mistaken), but the academia only produces more than 1000 graduates per year. The academia is not able to meet the demand for programmers.

But what if there is another solution to this problem?

"This is a lie"


About four weeks before my talk for DevCon Davao 2017 last October 7, I started reading the “Rough Cuts” of Uncle Bob Martin’s book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” available at Safari Books Online. (I might find gems in it I can use to answer questions that might be thrown at me during the talk! :smile:)

The book was very good. Some blurry concepts, which I read in Uncle Bob’s blog and heard in his talks, were cleared.

But in chapter four of the book, he said this:

Of course, not all statements are provable. The statement: “This is a lie.” is neither true nor false. It is one of the simplest examples of a statement that is not provable.

I was skeptical about that.