Kanban vs. Scrum

Kanban is highly flexible with no fixed timeframes. In Scrum, work effort has to be estimated and organized into fixed-length iterations, known as sprints, typically lasting 2-4 weeks.

Kanban is better for projects with changing priorities, while Scrum is more suited for projects with defined requirements and deliverables. If continuous delivery is essential, Kanban might be the better choice. For projects benefiting from iterative development, Scrum is preferable.

For the type of work I am doing, I prefer using the Kanban method, incorporating daily stand-up meetings where each person speaks for no more than 5 minutes. This ensures that everyone stays focused and that efforts are concentrated on high-priority issues.

The Case Against Education

"The Case Against Education: Why the Education System Is a Waste of Time and Money" by Bryan Caplan argues that a significant portion of education is not about acquiring useful job skills, but rather about signaling to employers. Caplan suggests that much of education's value comes from the signal it sends about a student's intelligence, conscientiousness, and conformity, rather than from the skills and knowledge they acquire. He believes that this signaling explains why employers value degrees even in fields unrelated to the job. Caplan also argues that this focus on signaling leads to a waste of resources and time, as students are made to learn subjects that are not directly useful to their future careers. He suggests that a more efficient educational system would focus more on vocational training and less on traditional academic education. He dispels many arguments that are taken for granted by looking at actual numbers.

Outsourcing software development

When outsourcing parts of a software development project, you'll need to overcome several challenges:

Clearly Define the Problem and Verification: It's essential to have a detailed design and create prototypes for testing your ideas before writing a statement of work. The outsourcing partner mainly contributes in terms of usability and maintainability, i.e. they should convert the proof of concept that can barely be used by experts to a product that can easily be used by normal people.

Identify Reliable Partners: This is arguably the most challenging step. In the software world, many claim expertise – after all, it's just coding, right? However, the ideal scenario is knowing firsthand that the team or individuals you're considering are truly capable of handling the project. If you are not sure, starting with small scale (~1 week) discovery projects (free of charge) will be helpful.

Manage Budgetary Constraints: As costs rise, so does the bureaucracy and the number of required approvals. One effective way to control cost is to narrow the project's scope and build on top of open source. While it's imperative to obtain the source code from your partner, consider handling documentation, formal verification and maintenance internally.

By adhering to these guidelines, you maintain control over the project and its future maintenance. You also gain access to top-tier talent that might not otherwise join your team, all while potentially reducing costs compared to in-house development.

Cybersecurity

When deciding on the level of cybersecurity rules to enforce, there is always a tradeoff between security and cost (money and more importantly workplace efficiency). Since 100% cybersecurity is not possible, risk tolerance becomes important.

The first step of cybersecurity is identifying the threat: Are you trying to prevent middle school kids from gaining root access to your servers or do you have national security agencies in mind? Are you trying to prevent data leakage or data corruption? If you want to minimize leakage, is your data really worth the protection cost? People confuse value with secrecy. Something valuable does not make it automatically secret. Many things in life are valuable but not secret. In my experience, the real secrets are far less than what is commonly claimed. Classifying threats and security levels requires individuals who are both experts in security and are aware of its costs. Good luck finding them. Your typical security advisor has a vested interest in scaring you enough to sell you expensive products.

Risk averse managers lean on more and stricter rules. Managers become risk averse when the expected value of taking risks is low for them personally, i.e. when managers are punished when a risk is realized but not rewarded enough when the benefits of taking risks are reaped. In other words, when loyalty is more important than competency.

What is worse is that stricter rules may create the illusion of security (Security Theater) but can actually decrease it. For example, if you force employees to change their passwords every week, they will use more predictable passwords and even write them on Post-its and attach them to the side of their screens!

In such an environment, the cost of lower efficiency almost never comes up in management meetings and that cost is passed on to the lower level managers and engineers. If you are a software developer, your build times increase and sometimes fail. You have to spend a week to find out that the security software was blocking it, and inform the IT department to make an exception for your build. Since software is an ever changing field, you face such problems regularly. If there is a security breach, individuals are held responsible and the system is never questioned. In the long run, this causes longer shipping times, low quality, low morale and loss of personnel. In short, less security and less value to secure...

You have to make peace with the fact that a security breach will eventually happen, similar to earthquakes. What I propose is to use a minimal set of malware scanners and to focus on preventing data corruption by having good backup systems in place. Regulary check that you can build back your system from those backups so that a corruption will have minimal impact.

For more, see my previous posts.

Filtering software product ideas

A typical response I get from people when they learn that I am a software developer is, "I have this app idea X, does it have potential? Would you be willing to implement it?" In software, any idea can have potential, so dismissing it outright is not logical. My default answer is, "That's a fine idea. If you write a concept of operation document detailing how the app will be used and why it would be useful, I promise that I will design and code your first version (MVP) for free," and I genuinely mean it.

This approach benefits me in three ways. Firstly, by refraining from saying 'no', I show respect for their ideas and creativity, thereby avoiding potential hurt feelings. Secondly, it allows me to focus on truly promising and well-thought-out projects, rather than getting bogged down in evaluating every idea that comes my way. Lastly, if an idea does prove to be good, I gain the opportunity to create value.

However, despite my promise to work for free, I rarely receive a concept of operation document. It's easy to have an idea but difficult to write it down. Also, when writing it down, they think more about it and usually realize that it wasn't as impressive as they initially thought.

Music: Damon Albarn - Sister Rust

Studying computer science/engineering vs AI

I was asked to provide an opinion on which undergraduate program would be preferable between computer science/engineering and AI (artificial intelligence).

I strongly suggest studying computer science. In Türkiye, computer engineering and computer science are considered the same, but in other countries computer engineering might have more hardware focus, which is a disadvantage compared to computer science programs in my opinion. Be sure to check their curriculum for specifics.

I also asked an AI engineer at my workplace and he said it would be much better to study computer science because it provides you with a lot more options. If you are keen on AI, you can start computer science, have more than enough AI skills by taking AI elective courses in the 3rd and 4th year. However, if AI does not meet your expectations or align with your interests as you progress in your studies, you can always work as a computer engineer. If you do an undergrad in AI, your options are limited and it is difficult to switch to other fields, don't be tempted by the recent popularity of AI. While a computer engineer can easily become an AI engineer, the reverse is much harder.

Here is a completely free Computer Science curriculum. Also check out my mentoring blog.

Music: Rammstein - Mein Herz Brennt

Using chatGPT in my writing

I use chatGPT to improve my writing, especially for German and English texts.

Example 1: A month ago, I got a job offer from an Austrian company. While preparing for the interview, I used GPT to clarify some questions I had about typical German expressions. For example, I asked GPT to translate "could we continue in English" to German and it answered "Könnten wir auf Englisch weitermachen?" as I expected. I thought about using the word "fortfahren" instead of "weitermachen". I asked GPT "what is the difference between fortfahren and weitermachen". It provided a detailed answer but what surprised me was that it also said "...in your sentence "Könnten wir auf Englisch weitermachen?" the word "weitermachen" is more appropriate because it refers to continuing the conversation in English. If you were to use "fortfahren", it might sound a bit more formal or less natural, though it wouldn't be incorrect." GPT's ability to keep the context in mind is not something you can do with ordinary Google searches.

Example 2: I usually start a post with handwritten notes:

Then I convert my notes into a coherent whole. When I feel like there might be a better way to express an opinion but cannot remember the expression or when I am in doubt about an idiom or grammar I ask GPT:

• Question: Check for spelling errors: (paste text) Answer: Shows me spelling errors
• Question: "have enough sleep" or "get enough sleep" Answer: "get enough sleep" is more commonly used and idiomatic
• Question: May I use "they" for "someone". Answer: Yes, you can use "they" as a gender-neutral pronoun to refer to "someone"
• Question: check grammar: It is depressing to realize the difficulty of changing our own faulty ideas, let alone changing others. Answer: The grammar in the provided text is correct
• Question: make better: This increases the chance of meeting someone compatible a lot Answer: "This significantly enhances the likelihood of encountering a compatible individual."
• Question: Would it be better to use "adult" instead of "equal" here: To avoid being influenced by charming yet superficial rhetoric, don't be flattered by being treated like a princess and instead maintain an expectation of being treated as an equal. Answer: Considering the context of the sentence, where the emphasis is on avoiding superficial treatment and maintaining a balanced dynamic, "equal" seems more appropriate.
• Question: rate the English level of this text out of 10: (I paste the whole blog post) Answer: The text demonstrates a good command of the English language. Overall, I would rate it as a 9 out of 10.

I can confidently say that chatGPT improves my text from being 7/10 to 9/10. It makes writing much easier and fun, I feel like I am discussing it with a knowledgeable friend.

13.08.2023: DeepL write is also nice.

Music: Nina Hagen - Du hast den Farbfilm Vergessen

Relationship Advice

Recently, a 24-year-old female acquaintance asked me about how to find a partner for a long-term relationship. Here is my perspective:

• To avoid being influenced by charming yet superficial rhetoric, don't be flattered by being treated like a princess and instead maintain an expectation of being treated as an equal.
• Having a strong attraction towards someone does not automatically indicate that they are your soul mate. Our brains have a tendency to rationalize our emotions, so it's important not to let it deceive us. It is advisable to maintain a clear and rational mindset by seeking the opinions of trusted individuals.
• Romance and long-term relationships are completely different. For a long-term relationship, you need an intelligent, caring and confident person who you can rely on. Do you think such a man might trust and respect you? If not, work on becoming such a woman.
• Instead of fixating on finding a partner, channel your energy into personal growth and enhancing your interests. Share your passions with others and consider creating online content that aligns with the interests of the people you'd like to meet. This provides a common topic to talk about and significantly enhances the chance of getting in touch with a compatible individual.
• The easiest way to find meaning in life is by engaging in activities that you enjoy and that also bring value to others.
• Your health is your most important asset, without health, nothing matters. Exercise daily, get enough sleep, stay away from smoking, alcohol and drugs.
• Be prudent with sexual relationships, the more your body count, the less attractive you will be.
• Dressing modestly instead of provocatively can help your potential partner get to know you better without unnecessary distractions.
• Personally, my most important criteria is to be able to have a conversation for long hours about a wide range of topics, not just about how much you miss/love each other. This demonstrates curiousity, sound reasoning skills and increases the likelihood of successfully resolving future conflicts that are bound to arise once the infatuation subsides.

Understand that finding a long-term partner may not happen quickly, concentrate on becoming a high-quality human being first and looking for a partner second.

Music: Paradise - Coldplay (Fingerstyle Guitar)

Becoming a 100X Engineer

To become a 100X engineer, always ponder the following questions before attempting to solve a problem:

1. Is this problem worth solving right now?
2. Would buying an existing solution be feasible?
3. Would outsourcing be feasible?
4. What is the simplest design to solve this problem? Simple is smooth and smooth is fast.

Music: The Wellerman (Sea Shanty) 

Engineering Design Document

Recently I have been asked about how to write a design document for a hobby rocket project. I have written about software design report before, but physical engineering disciplines have different needs (I am a mechanical engineering graduate). Here are the sections I would cover (with help from GPT4):

1. Introduction: What problem are you trying to solve and why? Example: "I am trying to build a model rocket because I have an interest in model rocketry and it might provide me valuable real life experience as an engineering candidate."
2. Requirements: List all the specific requirements and constraints that the rocket must meet. This can include factors like desired altitude, payload capacity, stability, safety regulations, and motor selection. Example: "I want a rocket that carries a 1kg payload to at least 100m altitude without losing control"
3. Literature/internet survey: What solutions have others come up with before you?
4. Safety Considerations: Address safety concerns and precautions that must be taken during the design, construction, and launch of the rocket. Include information on safety codes, launch site selection, launch procedures, and recovery considerations.
5. Sub-problems and potential solution candidates, including preliminary calculations, sketches/drawings for propulsion, aerodynamics, control/avionics, recovery, structure, construction techniques.
6. Budget and Schedule: Include a section outlining the estimated budget for the project, including material costs, equipment, and any other expenses. Additionally, provide a timeline or schedule for the design, construction, and testing phases.
7. Comparison of solution candidates, selection of solution and the reason why you selected it.
8. Simulation and Testing: Describe the simulation tools used to predict the rocket's performance, stability, and trajectory. Discuss any physical testing methods used to validate the design, such as ground testing or test flights of prototypes.
9. Conclusion: Summarize the key points of the document and restate the objectives of the rocket design. Mention any further steps or considerations that need to be addressed before the construction phase begins.
10. Future work: What would you like to do in the near future, what additional problems would you need to solve to achieve that.

Mühendis için İngilizce

Günümüzde mühendislik bilgisinin neredeyse tamamı İngilizce dilinde olduğundan mühendis adaylarının iyi derecede İngilizce bilmesi çok önemli. Ne kadar iyi bir mühendis olabileceğin İngilizce seviyene doğrudan bağlı. İngilizce seviyelerini şöyle sıralayabiliriz:

1. Lisede öğretilen gramer, kalıp ve kelime dağarcığına hakim olmak.
2. Wikipedia'daki Scientific Revolution sayfasını anlamak.
3. YouTube'daki The Untold Story of Air France 447 videosunu anlamak.

Sinema filmlerini anlaman o kadar önemli değil çünkü fazla sayıda deyim kullanıyorlar, teknik içeriğe sahip videoları tam manasıyla anlamak daha mühim.

Seviyen hakkında fikir sahibi olmak için Cambridge English testine benzer testleri kullanabilirsin. İleri seviye İngilizce puanı 90/100 ve üstü. Şu an o durumda olmayabilirsin, önemli olan sana uygun öğrenme yöntemini tespit etmen ve her gün düzenli olarak çalışman.

İngilizce öğrenmeyi ilginç bulduğun konularla birleştirirsen sıkıcılığı azalır. Ben geçmişte ilgimi çeken konulardaki İngilizce metinleri okur, bilmediğim her kelimeyi, İngilizce açıklamasını ve örnek cümleyi küçük bir deftere not eder ve hep yanımda taşıdığım bu deftere her fırsatta (sırada beklerken vb.) bakardım. Günümüzde defter yerine flashcard uygulaması kullanılabilir. Yararlı bir başka araç Duolingo.  chatGPT çok iyi bir yardımcı, kullanmanı öneririm. İlgini çeken konulardaki İngilizce Wikipedia sayfalarını ve YouTube videolarını izleyebilirsin, videoları düşük hızda oynatarak daha kolay anlayabilirsin. Son olarak bir blog açmanı ve şu anki İngilizce seviyenle ilgilendiğin/öğrenmekte olduğun konularda İngilizce yazılar yazmanı öneririm. Bloğunun linkini benimle paylaşırsan sana geri bildirim de verebilirim. Biliyorum, bunları sürekli yapmak biraz zahmetli ama başka bir yolu da yok. Kaliteli işler yapmak için iyi bir mühendis olman, iyi bir mühendis olmak için de en başta iyi İngilizce bilmen gerekiyor.

Expectations vs. reality

During my 26 years of engineering, I had my fair share of failed projects. These projects never failed due sabotage or lack of effort. In the aftermath, everybody, from engineers to the customer, was miserable. It makes no sense to blame the people in the project for not having tried hard enough, because they did their best, even burning out in the process. 

The root cause of defeat was always a gap between expectations and reality. Reality includes difficulty of the problem, available budget and quality of personnel. Not understanding reality resulted in short deadlines and low budgets, which in turn assured failure. If expectations were more in-line with reality, all that money and effort would not have gone to waste and a valuable end result could have been achieved, avoiding lots of unnecessary suffering. The only way out of this spiral is having competent, experienced managers who have a strong link to reality, and therefore can help align expectations with resources. Further reading.

Why college?

Recently I came across this short clip where the argument for college/university education is demonstrating to potential employers your discipline and hard work. In my opinion, the fact that you have been able to finish high school shows more than enough that you have the discipline to get up and go to work every day.