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

I was at the PSITS Intercampus Convention at Isulan, Sultan Kudarat...


Logo of first PSITS Intercampus Convention of SKSU - Jan 2018

My teacher in college, sir Elmer Buenavides, who is now the dean of the College of Computer Studies at Sultan Kudarat State University (Isulan Campus), invited me a few weeks ago to be one of their speakers (and judge of some contests) of their first PSITS intercampus convention. I first hesitated to respond positively to his invitation… because I’m not a very good speaker (I’m not an “in-born speaker” :laughing:, if there is such a thing), and because I needed to study or review something to prepare myself for a possible interview (which will not happen anymore because of some changes in plans). But he was able to persuade me, so…

The Principle of Priority


While browsing through my notes on The War of Art of Steven Pressfield, I found this:

I’m keenly aware of the Principle of Priority, which states (a) you must know the difference between what is urgent and what is important, and (b) you must do what’s important first.

I heard a similar statement from Uncle Bob in chapter two of Clean Architecture: A Craftsman’s Guide to Software Structure and Design.



The last time I remember hearing that word is when it was used by our most senior software developer in my second job.

He said that he wants us to be proactive, and not just reactive.

What does that mean?


Am I really a Christian?... just an undisciplined one?


What does it take to be a Christian?

I was taught that if there is at least one point in your life where you believed in Jesus Christ as your saviour then you are a Christian.

But I was also taught that there are real conversions and false conversions.


Then… I saw some facebook posts that say something like, “to be a Christian, you must believe and continue to believe”, or something like that; “you must repent and continue to repent”… (and the Shocking Youth Message of Paul Washer also!)

A better way than OO!... and TDD?


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.