4 ms·

I don’t really know what “think algorithmically means,” but what I’d like to see as a lead engineer is for my seniors to think in terms of maintenance above all

I don’t really know what “think algorithmically means,” but what I’d like to see as a lead engineer is for my seniors to think in terms of maintenance above all else. Nothing clever, nothing coupled, nothing DRY. It should be as dumb and durable as an AK47.

weatherlite 3y ago
We need this to be more prevalent. But the sad fact is most architects try to justify their position and high salaries by creating "robust" software. You know what I mean - factories over factories, micro services and what not. If we kept it simple I don't think we would need many architects. We would just need experienced devs that know the codebase well and help with PRs and design processes, no need to call such a person 'architect', there's not much to architect in such a role.
- Tade0 3y ago
  I was shown what it means to write robust software by a guy with a PhD in... philosophy out of all things(so a literal philosophiae doctor). Ironically enough it was nothing like what some architecture astronauts wring - just a set of simple to follow rules, like organizing files by domain, using immutable data structures and pure functions where reasonable etc. Also I hadn't seen him use dependent types in the one project we worked together on and generics appeared only when it really made sense. Apparently it boils down to using the right tools, not everything you've got at once.
  - namaria 3y ago
    I love how so much of distributed systems/robust software wisdom is basically: stop OOP. Go back to lambda. OOP was a great concept initially. Somehow it got equated with the corporate driven insanity of attaching functions to data structures in arbitrary ways, and all the folly that follows. Because "objects" are easy to imagine and pure functions aren't? I don't know but I'd like to understand why corporations keep peddling programming paradigms that fundamentally detract from what computer science knows about managing complex distributed systems.
jpc0 3y ago
In my mind this is breaking down the problem into a relevant data structure and algorithms that operate on that data structure. If for instance you used a tree but were constantly looking up an index in the tree you likely needed a flat array instead. The most basic example of this is sorting, obviously but the same basic concepts apply to many many problems. I think the issue that happens in modern times, specially in webdev, is we aren't actually solving problems. We are just glueing services together and marshalling data around which fundamentally doesn't need to be algorithmic... Most "coders" are glorified secretaries who now just automate what would have been done by a secretary before. Call service A (database/ S3 etc), remove irrelevant data, send to service B, give feedback. It's just significantly harder to do this in a computer than for a human to do it. For instance if I give you a list of names but some of them have letters swapped around you could likely easily see that and correct it. To do that "algorithmically" is likely impossible and hence ML and NLP became a thing. And data validation on user input. So algorithmically in the modern sense is more, follow these steps exactly to produce this outcome and generating user flows where that is the only option. Human do logic much much better than computers but I think the conclusion has become that the worst computer program is probably better at it that the average human. Just look at many niche products catered to X wealth group. I could have a cheap bank account and do exactly what is required by that bank account or I can pay a lot of money and have a private banker that I can call and they will interpret what I say into the actions that actually need to happen... I feel I am struggling to actually write what's in my mind but hopefully that gives you an idea... To answer your nothing clever , well clever is relative. If I have some code which is effectively a array and an algorithm to remove index 'X' from it, would it be "clever" code to you if that array was labeled "Carousel" and I used the exact same generic algorithms to insert or remove elements from the carousel? For most developers these days they expect to have a class of some sort with a .append and .remove function but why isn't it just an array of structs which use the exact same functions as every single other array... That people generally will complain that that code is "clever" but in reality it is really dumb. I can see it's clearly an array being operated on but OOP has caused brain rot and developers actually don't know what that means... Wait maybe that was OPs point... People no longer think algorithmically. --- Machine learning, Natural Language Processing
- taneq 3y ago
jffhn 3y ago
>I don’t really know what “think algorithmically means,” I would say thinking about algorithms and data structures for algorithmic complexity not to explode. >Nothing clever A lot of devs use nested loops and List.remove()/indexOf() instead of maps, etc., the terrible performance gets accepted as the state of the art, and then you have to do complex workarounds not to call some treatments too often, etc., increasing the complexity. Performance yields simplicity: a small increase in cleverness in some code can allow for a large reduction in complexity in all the code that uses it. Whenever I do a library, I make it as fast as I can, for user code to be able to use it as carelessly as possible, and to avoid another library popping up when someone wants better performances.
tasuki 3y ago
> Nothing clever, nothing coupled Yes, simple is good. Simple is not always easy though. A good goal to strive for nevertheless. > nothing DRY That's interesting. Would you prefer all the code to be repeated in multiple places?
- f1shy 3y ago
  Bit OP but probably means “no fancy silver bullet acronyms”.
- dclowd9901 3y ago
  Depends. I haven’t come up with the rubric yet but it’s something like “don't abstract out functionality across data types”. I see this all the time: “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” Invariably it ends up collapsing, and if the whole program is constructed this way, it becomes monstrous to untangle, like exponentially complicated on the order of abstractions. I think it’s just a breathtaking misunderstanding of what DRY means. It’s not literally “don’t repeat yourself”. It’s “encapsulate behaviors that you need to synchronize.” Also, limit your abstractions’ external knowledge to zero.
  - tasuki 3y ago
    Very good explanation! > “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” I'm guilty of this. I even fought hard against the people who wanted to keep the code duplicated for the different data types. > “encapsulate behaviors that you need to synchronize.” I like that!
- manicennui 3y ago
  The problem is that most developers don't not actually understand DRY. They see a few lines repeated a few times in different functions and create a mess of abstraction just to remove the repeated code. Eventually more conditions are added to the abstracted functions to handle more cases, and the complexity increases, all to avoid having to look at a couple lines of repeated code. This is not what DRY is about.

weatherlite 3y ago

We need this to be more prevalent. But the sad fact is most architects try to justify their position and high salaries by creating "robust" software. You know what I mean - factories over factories, micro services and what not. If we kept it simple I don't think we would need many architects. We would just need experienced devs that know the codebase well and help with PRs and design processes, no need to call such a person 'architect', there's not much to architect in such a role.

Tade0 3y ago
I was shown what it means to write robust software by a guy with a PhD in... philosophy out of all things(so a literal philosophiae doctor). Ironically enough it was nothing like what some architecture astronauts wring - just a set of simple to follow rules, like organizing files by domain, using immutable data structures and pure functions where reasonable etc. Also I hadn't seen him use dependent types in the one project we worked together on and generics appeared only when it really made sense. Apparently it boils down to using the right tools, not everything you've got at once.
- namaria 3y ago
  I love how so much of distributed systems/robust software wisdom is basically: stop OOP. Go back to lambda. OOP was a great concept initially. Somehow it got equated with the corporate driven insanity of attaching functions to data structures in arbitrary ways, and all the folly that follows. Because "objects" are easy to imagine and pure functions aren't? I don't know but I'd like to understand why corporations keep peddling programming paradigms that fundamentally detract from what computer science knows about managing complex distributed systems.

jpc0 3y ago

In my mind this is breaking down the problem into a relevant data structure and algorithms that operate on that data structure. If for instance you used a tree but were constantly looking up an index in the tree you likely needed a flat array instead. The most basic example of this is sorting, obviously but the same basic concepts apply to many many problems. I think the issue that happens in modern times, specially in webdev, is we aren't actually solving problems. We are just glueing services together and marshalling data around which fundamentally doesn't need to be algorithmic... Most "coders" are glorified secretaries who now just automate what would have been done by a secretary before. Call service A (database/ S3 etc), remove irrelevant data, send to service B, give feedback. It's just significantly harder to do this in a computer than for a human to do it. For instance if I give you a list of names but some of them have letters swapped around you could likely easily see that and correct it. To do that "algorithmically" is likely impossible and hence ML and NLP became a thing. And data validation on user input. So algorithmically in the modern sense is more, follow these steps exactly to produce this outcome and generating user flows where that is the only option. Human do logic much much better than computers but I think the conclusion has become that the worst computer program is probably better at it that the average human. Just look at many niche products catered to X wealth group. I could have a cheap bank account and do exactly what is required by that bank account or I can pay a lot of money and have a private banker that I can call and they will interpret what I say into the actions that actually need to happen... I feel I am struggling to actually write what's in my mind but hopefully that gives you an idea... To answer your nothing clever , well clever is relative. If I have some code which is effectively a array and an algorithm to remove index 'X' from it, would it be "clever" code to you if that array was labeled "Carousel" and I used the exact same generic algorithms to insert or remove elements from the carousel? For most developers these days they expect to have a class of some sort with a .append and .remove function but why isn't it just an array of structs which use the exact same functions as every single other array... That people generally will complain that that code is "clever" but in reality it is really dumb. I can see it's clearly an array being operated on but OOP has caused brain rot and developers actually don't know what that means... Wait maybe that was OPs point... People no longer think algorithmically. --- Machine learning, Natural Language Processing

taneq 3y ago

jffhn 3y ago

>I don’t really know what “think algorithmically means,” I would say thinking about algorithms and data structures for algorithmic complexity not to explode. >Nothing clever A lot of devs use nested loops and List.remove()/indexOf() instead of maps, etc., the terrible performance gets accepted as the state of the art, and then you have to do complex workarounds not to call some treatments too often, etc., increasing the complexity. Performance yields simplicity: a small increase in cleverness in some code can allow for a large reduction in complexity in all the code that uses it. Whenever I do a library, I make it as fast as I can, for user code to be able to use it as carelessly as possible, and to avoid another library popping up when someone wants better performances.

tasuki 3y ago

> Nothing clever, nothing coupled Yes, simple is good. Simple is not always easy though. A good goal to strive for nevertheless. > nothing DRY That's interesting. Would you prefer all the code to be repeated in multiple places?

f1shy 3y ago
Bit OP but probably means “no fancy silver bullet acronyms”.
dclowd9901 3y ago
Depends. I haven’t come up with the rubric yet but it’s something like “don't abstract out functionality across data types”. I see this all the time: “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” Invariably it ends up collapsing, and if the whole program is constructed this way, it becomes monstrous to untangle, like exponentially complicated on the order of abstractions. I think it’s just a breathtaking misunderstanding of what DRY means. It’s not literally “don’t repeat yourself”. It’s “encapsulate behaviors that you need to synchronize.” Also, limit your abstractions’ external knowledge to zero.
- tasuki 3y ago
  Very good explanation! > “I did this one thing here with data type A, and I’m doing something similar with data type B; let’s just create some abstraction for both of them!” I'm guilty of this. I even fought hard against the people who wanted to keep the code duplicated for the different data types. > “encapsulate behaviors that you need to synchronize.” I like that!
manicennui 3y ago
The problem is that most developers don't not actually understand DRY. They see a few lines repeated a few times in different functions and create a mess of abstraction just to remove the repeated code. Eventually more conditions are added to the abstracted functions to handle more cases, and the complexity increases, all to avoid having to look at a couple lines of repeated code. This is not what DRY is about.