If you are a doctor, you definitely know that approaching a patient for a surgery has these following priorities:
1. Who: This is the most important thing in my service. If the patient dies or gets degraded, it does not matter "what I am doing with him" anymore. The game is over with his life.
2. What: The first question I ask to a patient is what symptoms it has. A lot of check ups are not necessary to do if the individual has no symptoms. We have to eliminate most of the case scenarios and focus only the most important ones that will likely to happen.
3. How: This is an important mission in helping patients to prevent diseases and be more pro-active. However, as a doctor, and many other doctors, they will say the same thing: We do not have "control" of what other people can do or not do in their life. We can give them advice, exactly the steps of what to do, and they may absolutely not follow it and put their health in high risks. I have seen many doctors aggressively help patients to be proactive and I admire them. However, the effectiveness to change individuals is up to them. What we can be effective more than the patients than us is the "what" and knowing how to keep "who" alive during surgery operations. We were trained for this and most of our experience is focused on those 2 parts.
1. External Goals: What matters is the external symptoms of the patient. How patient feels in terms of pain, whether he can do activities, and other metrics to check the healthiness of the individual (blood test, blood pressure, weight, etc.).
2. Internal Goals: We do not have control of an individual make healthy choices in their lifestyle. Even for psychologists, whose main job is that, their jobs is actually how to make people be more social in the community (i.e. the invention of social support groups) and give drugs as a support for people feeling uncomfortable in their life. It is in some sense, a pseudo-science, apart from the normal sciences normal doctors do.
The main reason I went to programming was because there was attention to the above stuff, but in the opposite order. However, little did I found that executives and upper management people wanted to treat computers in the same way as doctors do.
Computers work the other way around. They work in this way:
1. How: How you do it is the most important thing in programming. Getting the same results (="what") is not so important as how you do it. In here, we have the ability to "control completely" the entity to our own desires (in this case, the computer). They will always follow our commands. In such sense, given we have such freedom over that (compared to humans which are the opposite), this is the most valuable component in programming. Unlike doctors being professional and respect over others' preferences, here there is nothing wrong bursting out what is wrong or not. Here, arguments can be on fire like in the ancient times where philosophers quarelled from morning to night over "how" things should suppose to be for humans. And after debates, nothing personal should be taken, although we can have a grudge for it for a few moments for it. It is all to find the correct path.
2. What: Now this is a really good thing to focus. However, it is not so important. This may be the most important thing when you enter in a programming job. However, once you know most of how things work, you will see that the problem in organizations is more on "how they do things" instead of "what they know". If we can connect "how things are done", then "what we do" will flow smoothly. Instead, people attack the "what" directly in here (and also the "who" very wildly than you can ever imagine, which just gives me chuckles). I got this a lot from my previous job. Its just really hilarious that I am still hearing it.
- The real reason is people do not understand the program well.
- One of the problems is we get a lot of new hires which do not know how things work in our program.
- Communication is not effective, we have to consolidate and articulate things in one place.
3. Who: Oh god, this gives me chuckles. I have been a victim on this a lot of times and technological organizations are fully driven by this. I think high executives know that this game is just left to be played as a playground so competition and pressure can exist in order to increase productivity. However, let this be the only game people play around and you will be doing circles around. The thing is who is so important as how in the profession of a doctor. But tell me, does the individual really matter in a software development company? Unfortunately, I have to say, none at all. Person leaves. The system is "intact". Totally "intact". The system has not left, just the person. People in an organization that matters the most is how they did things in the system and what they knew. But most important of all it is how they did it. Many think programming is sports or a contest, but it is nothing like that. Your achievements is not so important in the programming community as much as showing practices to do a thing better. In the programming world, I wish people could just hang out and discuss how we can do things better instead of "diagnosing" each patient molecules of DNA. However, however, who said who is not important? People have their own problems and they must be addressed. However, this is not the thing that will make the organization go game over. Being professional while not honest is completely bullshit.
1. Internal Goals: The internal goals are so important in here. It is not really about understanding how the system works, but how the people work together to make things work. Most of my sections I discussed in this blog, I explained experiences that had a big lack of internal goals. I also placed foundations in here that really follows the theory of mental symmetry. Now, lets not joke around here: Every job in the world is all about technology, from finance to recycling plastic bottles. That means that ultimately our life will be oriented with technology. How does technology works? It works best by understanding on how are things done. If so, shouldn't our work align with what our product is in order to be honest? If so, we should understand how we work ourselves in the same way we have passion on how our work is done. Because how can we love something if we do not put any effort first to love ourselves (= how "me" works? ) ? Most of the problems happen here. People put too much attention on fixing the external problems and nothing to the internal problems of the organization. It doesn't work this way in here. You have to care how things work with people in organization instead of how yourself is placed or which departments/people should be promoted or demoted. The best organizations that work effectively have the right culture. However, the main effort is to push the internal goals of the organization in the right direction, there is no other way. Believe me, if you do not, you may feel your environment is a hell hole and you will want to hop on another job. And many hop out for the reasons of an organization not allowing its culture to move within internal goals and they did a correct choice. However, do not expect that moving to another organization will be better than the other as most fail at this goal horribly (but it gives you a fresh scratch cause you are a novelty to the new organization).
So the conversation is like going into a lab room, where doctors talk to each other:
- A: The patient is starting to have more symptoms. I am not sure if he will be able to survive at this rate in the long term. There will be more complications in the end.
- B: Do you think we should do a surgery to him?
- C: Yes, I think that is the best course of action.
So how a culture grows? I am not joking in here, but a culture grows by all sharing the same religion, and that religion can only be one and one only: apply scientific methods to the internal self. However, what is more interesting is we have a blueprint of abstractions how to do this. For instance, Perceiver mode is the mode where the individual always can be "unknown" to a thing no matter on what topic it exists. It is also where the more facts you gather , the more confidence you get. Doesn't that sound all similar? Isn't that how science today makes conclusions? Now, how can science make proof that the way it makes conclusions is the way conclusions should be made? In other words, how do we prove that "getting more data, we are more reliable on our results"? Is there a way to prove that other than to say because "by getting more data, we are more reliable on our results"? (=abstractions within abstractions - eternal loop) . And basically, there is no way to simplify that concept anymore. Once the concept cannot be simplified by another thing over it, it is a universal abstraction that applies internally to myself. And so, one step for a culture to grow is to understand not the system of a computer or the system of an existing project, but the system of ourselves, no matter how irrelevant it is in the topic of the work environment. So when you see a mercy person, how do you respond, how do you understand him? When you see a contributor person, how do you respond, how do you understand him? It is not only me that I should understand, but others to understand the same concepts of abstraction. So if a person comes and tells me with main goal or main priority to understand the system, it is more like saying to disregard if that will suicide the organization before we even completely find out how things work within the system (if the computer system will not take you over, people will). In that case, my aspirations/goals tend more to put some effort on fixing or giving lessons to the internal problems of the organization that so much less is paid attention to the organizations these days. I will definitely chuckle about converting people on a religion as that is completely cynical. I do not think anything is easy to believe without some form of transition. A healthy internal culture is the same as a healthy patient for a doctor. "what" is irrelevant in that sense, as we only care about "what" when the "internal culture" does not work. Once the internal culture works, you will need less effort to "find what" to know because everybody in their specialized field will be able to do and collaborate effectively.
2. External Goals: Those are important and its the core focus of taking lead in an organization. However, this is not the ideal path to take but it is the starting communication form to build relationships as this is how most people think long term wise. Like I said before, I do not think it is easy for anyone to believe your ideas, they always need a form of transition.
Case Scenario
I have given a lot of talk on my past experiences. But still, I haven't talked in detail about my summary of my previous work.
One of the biggest hurdles my previous company had was their program being buggy. A big reason that happened was due to lack of internal factors, which if you are interested to learn more, you can find them in most of my previous blog posts. In summary, people are not interested to learn new philosophies in programming or connect bridges for collaboration (I do not want to give examples how that happens, but it is pretty pretty ugly).
The second hurdle is "how" things are done. Like I said in my previous paragraph, there was no much interest to design better systems of software compared to the time to satisfy the customer's requirements. But that is not because they really did not know that their "how" was missing, but because:
- They think "who" is the one that aggravates the problem. Names were blamed to almost everyone, spontaneously.
- Focus on "external goals" does not give space for "me" to align in the same way to the "internal goals" a system should be, which is to focus more time on "how" things should work A. within the internal organization and its employees B. within the clients they are addressing to C. the programming philosophies applied to the delivery product instead of just trying to understand "what".
However, let us "assume here" that the internal organization of the company was good at that time and QA was doing their job. I have this metaphorical example that I found as a reference.
There are three ways to fix a flat tire, and boy oh boy, it really hits the nail how the programming world is:
1. Pumping it with air. If it has holes, it will never get fixed. The driver can drive it for a while and look that it works normally, but not for the next day. With programming, it is the same. It can work the way we tried today, but if we try something different the other day, it will not work. This is just fixing an individualized case. Its more trolling instead of fixing the problem. And worst of all, it happens very often and sometimes due to the specifications of the bug not described clearly.
2. Fixing the holes of a tire. Fixing holes is good, but not the best. Not recommended if the tire is not good quality. In software terms, we look how everything works instead of only looking at an individualized case. If the tire is in poor quality, we add "more variables" or "more logic" that will make the system more confusing to maintain. That is like putting a lot of band-aid patches on the wheel. It will always "lose" air with so many holes that are not "patched 100% well". It will need patches over patches. You know how this ends up.
3. Replacing the tire. But be careful what tire you replace! If it is another low quality tire, you will have the same problems as before. That means if your new design is almost similar to your last tire, expect to get almost the same results.
When I tried to apply for a job, I was looking for job positions that met the Joel Test. One of the jobs met all the criteria except one: testing. I was kind of shocked that they did not do any testing. Can there be live code for big scale projects that need little to no testing at all? It quite in fact does, because they found better philosophical approaches on how to address the issues of code design by using different technologies and platforms.
Nobody will argue that C/C++ is more powerful than .NET . Yes, C/C++ is less productive, more technical and harder for business users to understand, but more efficient at making stuff. Yet, both still have a lot of issues with addressing bugs.
So now, I am looking at a different philosophical approach of addressing some of the programming problems that need a different type of mindset: functional programming. Yes, this can be done in an imperative language with .NET and C/C++, but if you use any of the libraries from them (which I think its impossible you don't, as the main point of productivity is using its libraries), you will not be doing functional programming and you are dependent on them.
One of the main things in functional programming is that it does not have side effects (which is not just only removing dependencies, but also making sure it returns a result, which result is always the same as long as it is given by the same parameter). Then you have to be honest, where you cannot make the "assumption" the program knows about the world. You have to explicitly tell exactly default values you assume you didn't need to tell. In summary, this removal of side effects substantially will help the issue of finding the original place of the source bug. However, functional programming languages are very difficult to learn (it is not taught in universities), small in supply (high in demand) and is only good for large scale projects as its productivity rate is not in par with .net language. I am now more interested how functional languages like Haskell works, but I know it will take me at least 3 years to be able to write comfortable serious live production code for it. For the mean time, I have set it as a goal to learn the concepts and changing my programming mindset through my free time.