DEV Community

loading...

How to win programming arguments?

koikoder profile image koikoder ・9 min read

Today there are hundreds of books, lectures and heated forum discussions regarding the best way to develop software. In this crazy brawl, there are very few rules but even those don't apply, depending on who is speaking.

It's very common to attend a speech titled: "Why X is simply better", "X is dead, long live Y" and "Y is root of all evil". To a bystander this is all silly, but in a way it increases exchange of different mindsets on the common topic - sometimes resulting in useful things that benefit everyone.

Surviving the brawl

However, what happens if you are involved in such an argument? What would you say? Are you ready to face the demons? It's a scary world out there, but fear not! you are in the right place, I will teach how to make proper arguments when confronted with different opinions about programming.

In this post I will teach you 5 very powerful techniques that will help you win arguments about programming.

1: Mythical saboteur

This is a very common character who defends software decisions that are hard to reason about. Basically reason you wrote code this way is because there might be a programmer in the future who will use your code without understanding and then make a huge mess and destroy everything. Basically if there is a way to mess it up, he will do it, he is practically paid to do it.

2: Educational high horse

If you have a computer science degree you can invalidate all arguments from people with engineering degree, and engineers can invalidate code boot-camp graduates. What's great about this technique is your current skill level is completely irrelevant.

3: Dash of popularity

This technique allows you to validate your decisions based on the success of giants that came before you. In other words, the reason you decided to go with this tech or architecture or have used this specific algorithms and storage solutions is because BIG_TECH_COMPANY_NAME did it and it's obviously working for them. It's good to use XYZ because it's used by millions of other developers, not because it's any good. Software development is not about solving problems, it's about swiping problems under the best looking rug.

4: Power of age

If you are more experienced than your current foe you will immediately win an argument. It does not matter if you spent years planting potatoes in the mini garden next to your desk or actually learning new things and gradually improving. If you are the former you also got experience in agriculture which acts as a power multiplier, since you are practically working in two sectors at the same time.

5: Programming Guru's tongue

If all else fails, this is your only chance. You read books right? or you bought one and you know it's good, because other people told you it's good. Now, all you need to do is state that the reason you did things in this way is because BOOK_AUTHOR_ID said this is how it should be done. If you can provide a quote you are awarded extra points. What's also really nice about this technique is that you get to become a really good programmer really quickly. Many of these books are labeled as "books that every good programmer reads" - so if you are reading these or have already read them you are a good programmer.

Reality check

Reason why you think your ideas are always better than those of another person is because you are experiencing these opinions forming in your head in first person. It's super easy to re-assure yourself that you ideas are valid when 90% of the time you are confronted with your own ideas. It's hard to think that 10% of ideas - those that come from outside are any better than ideas that are spinning endlessly in your head.

Someone who had been taught that object oriented programming is the one and only way to develop software for all of their lives will have hard time accepting that it's not a best technique to solve all problems. When confronted with someone who prefers procedural way of programming they are likely to think of other person as a fool, someone who is not experienced or skilled and has lost track of time.

Our minds are not as clear as we think they are, even in the best of circumstances our thoughts are affected by various cognitive biases. One way to avoid falling into these traps is to avoid thinking about the problem outside of this problems existence. Do not think of problem in terms of something that needs to be adjusted to fit your theoretical ideals. Engineering is not an ideology, it's therefore not possible to side with ideals that do not fit the objective facts and expect good results (unless your idea of good results is skewed).

Example of a dogmatic view

For example, say I believe no function should exceed line count of 10 and therefore write out larger operations as set of small functions that are perhaps called in one aggregate function that describes that operation.

Obviously this depends on context, but it's not likely that we find problems on a small scale, but as project grows our function count grows exponentially. Most obvious consequence of this is performance will likely go down (more for real-time applications). Another consequence, which might not be obvious is that code is now many times harder to understand, every function is a new name that a programmer needs to understand in order to know what this code is doing. In order to piece together information programmer must jump around the code to find all the sub-functions that make this one operation. Furthermore once mindset of "let's separate all the things!" sets in - you likely separate these functions into many more files than you would have had otherwise, so you also have more files in your project to search through in order to find what you need.

This is a very simple example of how programming Guru's of today sell untested ideas that will likely do you more harm than good. We can distil this formula like so:

  1. Present something inconvenient: "There is this code base from 2007 written in XYZ where reason for company's downfall is that functions exceed 800 lines of code and are therefore impossible to modify and build upon in the future. Do you have such a problem?"
  2. Present a solution: "No function should EVER exceed 10 lines of code."
  3. Explain why this works: "It works because large operations are ALWAYS just set of smaller operations that are easier to think of in isolation."
  4. Give absurdly simple example to solidify your point

Critique of programming Guru's

Most of times when I had conversations about some concepts presented by some "programming Guru", say Uncle Bob, were with students (or colleagues back when I was a student). I've been to various software development conventions, however even there people that were most engaged in these topics were students. This makes perfect sense, since students are learning and are always looking for a way to become better at their craft. While it's great that students have a drive to become better, it's also a bit tragic because they are exposed to what I would call "programming telemarketing".

I think software engineers carry with themselves responsibility to pass knowledge to future generations. Not everyone has to fulfill this duty, but those that do should do so cautiously.

Many times when reading about software engineering I felt like I was sitting through a commercial. There is nothing wrong about having an opinion, but there is everything wrong about stating that you opinion is absolute - especially when there are no objective facts to back it up. Saying something like "NO function should be longer than 10 lines of code" is an example of such an opinion. It's okay to have it, but don't frame it as absolute truth, because there is no way to prove that this is the right way to write functions.

They say that a good lie is hidden behind two truths, using this I can give 3 advices for the price of 2 good advices. Say I wanted to give someone 3 advices on how to reduce amount of errors they have in their code:

  1. Name your functions sensibly
  2. Handle any error-prone behavior with exceptions
  3. Document your code well

Pass knowledge not ideals

In my opinion, you can pass most valuable knowledge by explaining how things work. In many ways software engineering has shifted towards code, but most of our job is problem solving not writing code. Code is the final part of the puzzle and a minor part of software engineering. It's my opinion that solution should lead the code and not the other way around.

Understanding of the machines that actually make this code do anything is in my opinion way more important than knowing some abstract idealistic set of principles such as SOLID. Why is that these things are given more importance?

Cynical way to think of it is that people by nature are more inclined towards goals which are smaller but much easier to achieve. Perhaps our brains are wired in such a way that we always seek to min-max our efforts.

In case of learning something like SOLID principles over how computer memory is managed. SOLID principles are much easier to grasp, in practice these are good for getting through some programming interviews, but no more than that, these are rarely applied and in cases when they are it's no better than "regular" code.

Understanding memory management on the other hand is always useful, even when using languages where memory management is taken care of by something like garbage collector. Concepts around memory management take much more effort to understand and in practice this knowledge is always useful, it's equivalent to understanding that Earth is not flat and things fall down due to gravitational pull. Not every engineer might find this information practical but at the very least it provides a baseline or point of reference onto which you can build more knowledge that is factually correct. In practice it's used to work around Von Neumann's bottleneck, yielding massive performance and memory efficiency benefits.

Something that programming Guru's are unable to sell is how to think in a critical way and produce a creative solution that actually works. However they attempt to sell "best practices" which try to mimic the same ability - but without need for understanding how anything really works, it's kind of like those "get rich quick" deals. Mostly these are isolated cases turned into dogmatic rules. For example, if you ever de-referenced a null pointer and it crashed your application - you should from this point onwards avoid pointers at all cost, right?

Keep it simple, stupid

Reason why many programmers turn to these Guru's for answers is because our industry is very wide and there are many valleys and mountaintops to explore, so it's not unusual to be lost from time to time.

One methodology that I personally rely on when I'm lost is KISS (or "keep it simple, stupid"). Big problem with large OOP/SOLID codebases littered with Design Patterns is that there is a lot of code that is used to "organize" rest of the code. Selling point here is that this code will be easier to maintain and work with. I find this to be a bit ironic, considering that most of such code makes it much harder to understand what's going on and therefore defeating it's purpose. This is obviously my opinion, but consider the following very real example of such code:

/**
 * Convenient superclass for FactoryBean types that produce singleton-scoped
 * proxy objects.
 * ...
 */
@SuppressWarnings("serial")
public abstract class AbstractSingletonProxyFactoryBean extends ProxyConfig
        implements FactoryBean<Object>, BeanClassLoaderAware, InitializingBean { ... }
Enter fullscreen mode Exit fullscreen mode

DISCLAMER: from this point post is no longer family-friendly.

This wonderful example comes from Java Spring Framework code. All that it takes for someone to realize that this code is no good is one look at this class declaration. Java developers I'm sorry and I'm even more sorry if you like Spring framework. But this code is in my opinion prime example of programmers who have lost touch with reality and should seriously re-consider their career path.

In many cases developers try to write less code, reuse and make things as flexible as possible per default. I believe this approach is wrong, because in doing so all of the code quality is crippled to the point where codebase looks like repetitive set of vague descriptions of things it's supposed to do. There is no substance to such code, it could have been much smaller and easier to understand. Furthermore, this approach is sold far and wide because it "helps you develop applications faster" but in reality such projects are frequently late. I argue it's not really about the methodology, but rather about individual skill of programmers working on an application.

My advice to those that feel lost is: write bullshit-free code, write code that does something and don't stress over reusability/flexibility/etc. if you are doing it right valuable abstractions will arise on their own. While this might not be helpful as it's not "become a great programmer in 1 week with this book" type of deal, it's how things actually work in real world.

Conclusion

Don't end up in an echo chamber, assume that different opinions hold some value and allow objective facts to lead the way.

Learn about computers at your own phase and don't listen to people who tell you not to care about "XYZ" because "A" does that for you, only way you will learn things is if you give a damn.

Don't spend your time on silver bullets and do not allow others to force you to work in their broken way just because you feel lost. (Hopefully you can see what I did here)

Discussion (0)

Forem Open with the Forem app