Question

#

When is it appropriate to abandon a pull request?

Answer

#

Assuming that this is in a business context, you should abandon working on a pull request if getting the pull request merged is taking away too much time from others and it requires a lot of additional changes, creating a lot of back and forth between the creator and the reviewers.

You should abandon it if the feature/bug it fixes is not important enough compared to other more important ones. One should always work on the most important task rather than to work on tasks of lower importance. Furthermore, working on low importance pull requests will also “force” your coworkers to review those low importance pull requests, reducing the overall productivity. As such, always think of the impact you will have on others.

Many developers often think that bugs are of the utmost importance and should be fixed as soon as possible. However, implementing a good fix might require a lot of effort on the part of the person that will fix the issue, as well as a good amount of effort on the part of the reviewers which could have spent their time on features or bugs that are more important. Like anything else, bugs should be prioritized based on how important they are, not just that they are a bug.

Question

#

Why do we reinvent the wheel?

Answer

#

It is very common for developers to want to develop things themselves instead of reusing existing code. They prefer to know how it works so that if they need to make changes to the code, they know where to do it since they wrote it themselves. If they are lucky, they’ve been given a narrow set of initial requirements that could be fulfilled by a more complex/complete library, but they think that they can do it themselves or do it better. Thus they build themselves a square wheel.

One of the positive sides of developing something that already exists is that you can get a good understanding of what is required without having to consider all the other parts which may be required for other use cases. You’re also free to explore the aspect of the problem that you find interesting or challenging.

One of the negative sides is that if you work on your own square wheel for a while, you never end up learning a library that might prove more useful. You also do not acquire the skill of learning new libraries and their strengths/weaknesses, as well as how you could help to improve them. Sometimes however by reading an existing library you will come to the conclusion that fixing said library is likely to take you more time than writing a new one.

In my experience, the main reason that has led me to write something from scratch even though I had access to code that partially did what I wanted was because:

• the library wasn’t able to sell me on the reasons I should use it instead of doing it myself, while I considered implementing the solution myself to be somewhat easy.
• the code (organization, style) was so messy that fixing it would require more time than rewriting it after understanding the core concepts.
• the library was not maintained anymore.
• using the library would make my workflow slower.

References

#

• https://en.wikipedia.org/wiki/Reinventing_the_wheel

Question

#

If I were a billionaire, how would I live my life?

Answer

#

I would invest a good chunk of my money in doing research in the fields I’m interested in, namely biology, genetics, computer science, software engineering, machine learning and artificial intelligence. I would spend my time trying defining what is the most important thing I could be working on given our current understanding and constraints in order to reach certain objectives. I would want to get informed by the advice of the smartest people I can get. I would pay others to help me get to my goals faster. I would avoid having to deal with hardware constraints by simply purchasing more hardware. I would try to trade the money I have to remove as much friction as possible in my work. I would like to consider working on different things as having a variety of hobbies and not a variety of jobs. I would avoid spending my time commuting. I would eliminate the time I spend on cooking and cleaning. I would maximize the effectiveness of my time, from the moment I wake up to the moment I go to sleep. I would try to find ways to increase the number of people (or machines) that can help me. I would try to find ways to make the fact that I’m a billionaire irrelevant to the accomplishment of everything I’ve stated here.

Question

#

Is it better to spend a lot of time designing a great software solution or to implement an acceptable one?

Answer

#

In software development, the further you go down the development pipeline, the more expensive it is to change things. Once a solution is established and is being used by other parts of the code, replacing it becomes more expensive. Thus it would make sense to spend as much time as possible planning what you’re going to develop before you develop it. Sometimes you however do not have enough information to make an informed design decision upfront and you actually need to implement something to explore and understand what will be needed to solve the problem. The exploratory implementation you do may end up being satisfactory enough that you do not see the need to redesign your solution.

When you implement a solution you generally have an idea of the use cases you need to support, but sometimes certain use cases are less common and require a lot more effort to support. As such, you have the choice between implementing a solution that would support both common and uncommon use cases but would require more time, or you could implement a solution that covers the common cases. Depending on the field you are in, you will have to choose between this tradeoff.

In the domains I’ve worked (game development, web development, machine learning), it has been more valuable to implement an acceptable solution that could be shown as providing value to the client vs designing a great solution until it was proven to be necessary.

Always make wise use of your time and assess whether quality or quantity is needed for your software project.

Question

#

How do I improve my processes?

Answer

#

First and foremost, to improve any process you need to start by writing the process down. All the steps or things you need to consider should be written in a document. This will allow you to review this document over time and improve it as you find ways to make the process better.

When you perform the process, look at your document and see whether you are applying all of the steps you wrote down. Identify the steps that are more critical than others, in which order you complete them, how long it takes you to accomplish them, whether some steps are sometimes relevant, etc. You want to capture information about the process as you are going through it in order to identify sources of improvement. If a step takes the majority of your time in a process, ask yourself whether this is expected and whether it would be possible to optimize or automate this step in order to reduce the time spent on it.

If possible, share your processes with others. Have them share with you how they would go about doing the same things you do and take notes. Some of the things that may be different between you and others are the order in which you accomplish the steps, which steps you consider critical and how much time is spent on each step.

Even though some of the processes you follow on a daily basis may appear trivial to you, you might end up realizing that those processes are quite complex in nature, especially if you need to write them down.

Try playing around with doing steps in parallel vs doing steps sequentially and see which one is more efficient.

In order to improve your processes, you need to define what it is you want to improve. In my case, I want my processes to be efficient (doing things right) and effective (doing the right things). Compared to myself, a process is improved if I need less time to accomplish it while producing the same quality of results or if for the same amount of time I produce higher quality of results.

Question

#

Why do developers fight over code style?

Answer

#

We are creatures of habits. We like when our code looks like we would expect it to look and not some completely different style. When the style is too different, then it creates cognitive load, which means that we’re spending more energy than we would if the code looked the way we like it. Since we’re machines that attempt to minimize the amount of energy we spend, we see code that is not styled our way as a bad investment of our energy and that it would either be better to reformat the code our way (minimizing our energy expenditure in the future) or simply to start from scratch.

As human beings, we’re able to adapt. Adapting generally requires more energy than simply using the skills we already have, and we prefer to avoid having to adapt. Thus we fight with others so that they do the effort of adapting instead of us. We see fighting as being more effective than adapting. It may be an effective approach when no existing rules exist, however, in many businesses, code standards have been established, which means that if you are a new employee, you will have to adapt to those standards. You could always try to bring back the discussion of updating the code style, but if the standards have been established a long time ago, this effort is likely to be futile.

As such, even though adapting requires more of our energy, we should make that sacrifice upfront and use it on more important things, such as defining what tasks are important and which ones should be done first.

Question

#

If you offload everything in your head into documents, how long does it take before you start repeating yourself?

Answer

#

How soon you repeat yourself will depend on how much diversity there is in your thoughts. If you always think about the same problems in the same ways, you’re likely to repeat yourself a lot. However, if you try to explore the same problems through different lenses you’ll have less chances to repeat yourself.

If you spend most of your time exploring new ideas, then you may only come back to ideas you had in the past from time to time.

If you work in a specialized field you may have to learn the basics multiple times in order to master them. Sometimes you will have acquired new knowledge that might challenge your existing assumptions. You will be mostly repeating yourself, but you will be making small adjustments at the same time.

When we offload everything that we have in our head into documents, our goal is to have more working memory space for our current work. We want to avoid having to come back to the same topics and having to start our exploration from scratch.

When we’re exploring, we want to avoid exploring the same topics without noticing. As we explore a field, we may get a sense that the field is very large and that it may take a long time to get familiar with it. By mapping the field we can get a better sense of its size while at the same time discovering the important concepts. This lets us identify when we are making use of the same concepts over and over again.

Question

#

Should we let employees from corrupted companies apply to other companies?

Answer

#

I am of the opinion that it is better for corruption not to spread.

I’d hope that by having the (potentially) corrupted individuals join other companies, that the culture of the companies they join would prevent them from corrupting those companies. Either the corrupted individuals would have to stop being corruptors (in the future, which would be ideal), or be evicted out of the “healthy” company in order to avoid fostering this behavior.

One issue with corrupted employees spreading to other companies is that it is difficult to identify them as they work in those various companies. It is possible for us to establish a blacklist of companies that exhibited bad behaviors and avoiding employing people who worked there. This approach may however punish employees that are not corrupted. As larger and larger companies exhibit behaviors that might put them on this blacklist, the number of individuals ending up on that list may be too large, reducing the pool of candidates too greatly.

What companies and individuals within healthy companies need is a way to identify individuals that are likely to be corrupted or corruptible. The difficulty is however that those individuals are likely to be cunning, which means that no single technique will always succeed at identifying them.

Question

#

How do I track my thoughts?

Answer

#

When I am on the go, I mostly rely on Google Keep to write down what on my mind. I use it because it loads fast, is straightforward and allows me to quickly dump my thought and go back to what I was doing. Since I’m always with my phone, it’s always within reach. It also will synchronize with Google when I’m online so it is available on any other devices. This also means that I may sometimes record things either directly from my computer, my work computer, my phone or my tablet, depending on the medium I’m using at the time (defaulting to my phone if I’m not using any device when the thought crops up).

When I am at home, I’ve devised a simple system in Visual Studio Code where I use two keyboard shortcut, one that open today’s buffer (CTRLNumpad 2) and one that inserts a datetime and note id on the current line (CTRLNumpad 0).

When I am at work, I use this same system to take notes pertaining my work. I generally try to organize my thoughts per projects so that I can go back to any specific project and re-read the notes to get back in context. I also will write down notes related to issues I’m working on and identify them using the issue ID given by JIRA.

In both cases (at home and at work), I also have configured Visual Studio Code to commit automatically to git changes that are done in markdown files when the editor focus changes. This allows me to have a somewhat granular log of the changes that happen to my note files. At work, I have configured a cronjob that automatically pushes the notes to my private git repository. This allows me to pull those notes at home and read them whenever I want. I also push my personal notes to my private git repository, but I do not pull them on my work computer because I haven’t had the need for it.

References

#

• Note taking

Question

#

What simple questions can be used to think about a problem differently?

Answer

#

I’ve learned to solve problems by thinking about what I already knew. I would try to think of parts of the solution that might make sense and I would piece those parts together to get from the problem to the solution.

While I was doing some hobbyist research on AGI, I read George Pólya classic “How to Solve It”. Pólya covers many of the questions I would ask myself implicitly, so I was glad to see that someone had taken the time to write them in a reusable format.

His four steps of 1. understanding the problem, 2. devising a plan, 3. carrying out the plan and 4. looking back will lead you to ask yourself what you know and don’t know about the problem you are trying to solve. Doing so is similar to Feynman’s technique, where you attempt to teach what you know to someone else and by doing so, are discovering the parts of your explanation that needs improvement.

What I liked the most about Pólya’s approach was that he was comfortable working with partial solutions. If you couldn’t figure out how to get to the end, it was still important to put forward all the tools you had at your disposition in order to attempt to solve the problem. This way you would be able to get an idea of what was lacking in your solution.

Understanding the problem

#

• What is not known yet?
• What data do you have?
• What conditions are there?
• Is it possible to satisfy all those conditions?

Devising a plan

#

• Have you seen this problem before?
• Have you seen a similar problem in a slightly different form?
• Do you know any related problems?
• Do you know something that could be useful to solve this problem?
• If you cannot solve this problem yet, can you solve a related problem?

Carrying out the plan

#

• Can you see clearly the steps from beginning to end?
• Can you prove that your approach is correct?

Looking back

#

• Can you check your solution?
• Can you get to your solution differently?
• Can you use your solution to solve other problems?

References

#

• How To Solve It - G. Polya