3 ms·

And of course it depends on context. The interworking of a game engine may require some really obtuse code because it's focusing on performance and not on reada

by Osiris 5y ago

And of course it depends on context. The interworking of a game engine may require some really obtuse code because it's focusing on performance and not on readability (in those cases, comments should be used to explain the code). In my experience the problem with juniors is more about thinking about the problem in a very linear fashion and not stepping back to see it as individual parts. For example, I need to know when a user takes an action. So, I go into the code where that happens and throw in a bunch of analytics vs having a messaging system where events are raised and the code that handles those events are completely separate workers that are simple and easy to understand.

aYsY4dDQ2NrcNzA 5y ago
“We must always think of the Way of strategy as being both a rat's head and an ox's neck. Whenever we have become preoccupied with small detail, we must suddenly change into a large spirit, interchanging large with small. This is one of the essences of strategy. It is necessary that the warrior think in this spirit in everyday life.” — Miyamoto Musashi, The Book of Five Rings
cardanome 5y ago
> For example, I need to know when a user takes an action. So, I go into the code where that happens and throw in a bunch of analytics vs having a messaging system where events are raised and the code that handles those events are completely separate workers that are simple and easy to understand. It is interesting that you think that code with more abstractions is easier to understand. From my experience the simple linear beginner code is the one that is quite easy to work with. It is easy to grasp the general intention and to slowly refactor parts of the code if need be. Now a mid level developer that thinks of themselves to be smart and tries their hardest to use some fancy abstractions and patterns? Yeah, put it in the trash. We will have to rewrite that code. The best code is from the senior that finds the right balance. Finding the right abstractions to use takes years of experience. The most important rule when programming is: Don't try to be smart. Keep it simple.
- stouset 5y ago
  Code with more abstractions is generally easier to understand, which is precisely why most of us prefer to work in modern languages over assembly. And why we use SQL instead of working directly with low-level storage engines. And why most people prefer languages like Ruby and Python to FORTRAN and BASIC. It’s why we build software on top of an operating system and kernel, and now why we do so with the further abstraction of containers. It’s why we use an HTTP library for clients and servers instead of just writing and parsing requests directly on the wire. And it’s why io_uring is a stark improvement over select. The problem is bad abstractions. Bad abstractions don’t cut the underlying problem across clean axes, they leak too many implementation details, and they aren’t often able to be reused. “Linear beginner code” that handles too many concerns in one place is inarguably bad, but bad abstractions are generally worse. We shouldn’t be trying to stop using abstractions: virtually all of the history of progress in computing has been driven by finding good abstractions that allow us to build bigger and better things with less mental overhead. We should be doing absolutely everything we can to understand and teach the practice of writing good abstractions.

by Osiris 5y ago

aYsY4dDQ2NrcNzA 5y ago

“We must always think of the Way of strategy as being both a rat's head and an ox's neck. Whenever we have become preoccupied with small detail, we must suddenly change into a large spirit, interchanging large with small. This is one of the essences of strategy. It is necessary that the warrior think in this spirit in everyday life.” — Miyamoto Musashi, The Book of Five Rings

cardanome 5y ago

> For example, I need to know when a user takes an action. So, I go into the code where that happens and throw in a bunch of analytics vs having a messaging system where events are raised and the code that handles those events are completely separate workers that are simple and easy to understand. It is interesting that you think that code with more abstractions is easier to understand. From my experience the simple linear beginner code is the one that is quite easy to work with. It is easy to grasp the general intention and to slowly refactor parts of the code if need be. Now a mid level developer that thinks of themselves to be smart and tries their hardest to use some fancy abstractions and patterns? Yeah, put it in the trash. We will have to rewrite that code. The best code is from the senior that finds the right balance. Finding the right abstractions to use takes years of experience. The most important rule when programming is: Don't try to be smart. Keep it simple.

stouset 5y ago
Code with more abstractions is generally easier to understand, which is precisely why most of us prefer to work in modern languages over assembly. And why we use SQL instead of working directly with low-level storage engines. And why most people prefer languages like Ruby and Python to FORTRAN and BASIC. It’s why we build software on top of an operating system and kernel, and now why we do so with the further abstraction of containers. It’s why we use an HTTP library for clients and servers instead of just writing and parsing requests directly on the wire. And it’s why io_uring is a stark improvement over select. The problem is bad abstractions. Bad abstractions don’t cut the underlying problem across clean axes, they leak too many implementation details, and they aren’t often able to be reused. “Linear beginner code” that handles too many concerns in one place is inarguably bad, but bad abstractions are generally worse. We shouldn’t be trying to stop using abstractions: virtually all of the history of progress in computing has been driven by finding good abstractions that allow us to build bigger and better things with less mental overhead. We should be doing absolutely everything we can to understand and teach the practice of writing good abstractions.