What programming style should I follow

There is a story about a man who was walking around all day with his donkey. At mid day he was tired and decided to nap under a tree. Only, when he looked in his bag, he had forgotten the rope to tie the donkey to the tree. If he slept, he risked waking up to a missing donkey. A stranger passing-by saw his frustration.

"Why don't you pretend to tie the donkey with an invisible rope?" the stranger said. "The donkey will not know the difference."

So the man, who was too tired, followed the stranger's advice and fell asleep. To his surprise, when he woke up, the donkey was still there by the tree. He then decided to continue on his journey, but the donkey wouldn't move. Try as he may, the donkey just refused to move. So he went around the tree, untied the invisible rope, and the donkey finally followed.

---

When I sit down to program a feature, I split into two distinct people. One is a generalist without in-depth knowledge of the internals of the application. The other is an api developer.

These are the two important role you need to develop any applications.

The two personalities

When I wear my generalist hat, I care about one thing and one thing only. Make use of the available api to build the application. I don't want to know how to connect to the database. I don't want to know if the api uses a mysql database, or if it uses elastic search, or if it is a monkey typing the response real fast. All I care about is that I can call an API and it gives me the results in an agreed upon format.

As an Api developer, I do not care about the application the user is going to build with my tool. I just make sure that the user provides me with the correct information/parameters I need to retrieve the information he asks for.

Here is an example of how these two work together.

• Generalist: Hey I need the user's information.
• Api developer: And which user would that be?
• G: Well, the one I am currently working with.
• A: I don't know who you are working with man.
• G: Ey, do you have the user's information or not?
• A: I have the information of all users. Maybe you can give me the user's id?
• G: Yes, I have that. Here {1242njsdfaf23423423}
• A: Ok. Here is the information ({user information})
• G: Thanks. By the way, where do you keep all that information so I can get it next time without bothering you.
• A: Of course. It's in that place called NoneOfYourBusiness!

The Api developer will worry about the data storage. It can be an xml file, json, cockaroachDB, mysql, firebase. It shouldn't matter to anyone else. It can be upgraded, changed, scraped, and the end user should'nt notice anything.

This is one of the reason I don't like to see database connection code in my application.

Instead of this:

$con = new mysqli('localhost','username','password','database');

// stop if there is an error; 
if ($con->connect_error){ 
    die("$con->connect_errno: $con->connect_error"); 
}

// a simple query
$sql = "SELECT u.* FROM `user` WHERE user_id = 123 ";

// get the data from the database
$result = $con->query($sql);
$user = null;

// Now lets display it on the page.
while (($row = $result->fetch_array()) !== false){
    $tmp = new stdClass();
    $tmp->name = $row["name"];
    $tmp->picture = $row['picture'];
    $user = $tmp;
}

I would rather see this:

$user = DataManager::getUserInfo($userId);

No need to connect, no need to disconnect. No need to write a query. Just call the api and get the info you need.

How do you split the work?

In reality, I am one person that plays the many roles. When I am in the front end, I force myself not to add any code that doesn't belong there. Instead, I write a function name that will perform the task. I continue working, expecting that the backend developer will worry about the actual implementation of the api.

Of course, I am also the back end developer who will implement the code. But while I am doing frontend that's all I do. Later, I will come back to define the api. And while I am implementing it, I know what data structure the front end developer is expecting since he wrote all his code assuming my api works.

Like the donkey in the story, I create those invisible ropes around my workflow. These restrictions stop me from breaking the rules.

Everytime I come back to my code, it is with new eyes, like a different developer. This forces me to follow rules even as a single developer. I can't start making curl requests in the view because that backend dev would be pretty pissed if he learned. I can't break the rules in my html class naming convention because the CSS developer will also start complaining that I am making his job harder. The javascript developer is very annoying, he thinks he is on top of the world right now.

As a solo developer, this proverbial rope around my neck help me be more organized and allow me to build large scale applications by myself the same way a team of developers would. Yes, you need to develop a split personality.

Either that or I need to be psychologically evaluated.

---