8 ms·

I can't tell if this is an honest call to keep things simple, or if it's meant to ridicule that idea. Because I strongly, deeply agree with some of these points

by mcv 3y ago

I can't tell if this is an honest call to keep things simple, or if it's meant to ridicule that idea. Because I strongly, deeply agree with some of these points, and am absolutely horrified by some of the others.

mjr00 3y ago
> I can't tell if this is an honest call to keep things simple, or if it's meant to ridicule that idea. Me neither. All of these things involve tradeoffs. Multiple repos vs monorepo highly depends on your organization. Microservices vs monolith has been discussed to death. A simple, locally-driven deploy process is great for solopreneurs but doesn't scale to full companies. Load balancers might be required depending on your availability requirements. Storing all your data on disk is easier than maintaining a database, but aside from performance bottlenecks, it's harder to define a recovery process (RTO/RPO) in the case of a hardware failure. And as much as I dislike them, there are ease-of-use benefits in using dynamically-typed languages. The biggest technical challenge in most software engineering roles today is evaluating the pros and cons of these types of choices and choosing the right one for your situation.
- nerdchum 3y ago
  Yeah this is a sane take. Completely agree except for I think theres more performance bottlenecks with a database than files on disk no?
madeofpalk 3y ago
Skeptical of the person who is "not smart enough to figure out docker", yet is smart enough to know about building a "web application into a self contained statically linked binary executable file". I think they are smart enough, they just don't want to, or don't see the value in it (even if they've made an uninformed decision)
- mcv 3y ago
  Yeah, I'm not smart enough to figure out either. I'm smart enough to rely on the command line tools provided by the framework I'm using.
- onion2k 3y ago
  If you take 'figuring out Docker' as an open-ended problem then it makes sense. Getting an app running in a container is relatively easy, but that isn't really 'figuring out Docker'. That's just scratching the surface. Learning how to optimize that container, make it secure, put it in a registry so you can reuse it, etc means there's a lot to get through before you can say "I've got Docker figured out." There's no 'Done' when it comes to learning Docker. That makes it a harder problem in many people's opinions.
  - bbor 3y ago
    Idk this person claims they “can’t” figure out HTTP verbs and REST. I’d say there’s a very good chance “figure out docker” means “run a program in a container”
- foobarbecue 3y ago
  Yeah, how does one do this? I see something called bakeware that does it for elixir... Is that what the author is using?
  - creshal 3y ago
    Golang makes it very easy, e.g.
  - girvo 3y ago
    Nah they just use Go, so they get that outcome mostly for free, based on their other blog posts anyway.
- duhsuh90 3y ago
  Many doctors watch videos at 1.5X speed or they can not take in the information. If its too slow their brain switches off. I find I have this problem too and i havent figured out docker either even though im a ninja at programming.
jamil7 3y ago
Yeah, I really can't tell if it's satire. Especially things like this: > I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer. OK, well then you might need to gather a little more work experience and meet the repercussions of decisions like this one. Or maybe the OP is a contractor and never has to deal with the repercussions of their actions.
- HideousKojima 3y ago
  And they'll also run into major liability issues when they leak customer credit card information, SSN, or something similar because they have a single class that represents the table in the database and they use it in both the frontend and backend.
  - nerdchum 3y ago
    how does the "structure" of the data have anything to do with leaking information? Seems like data protection occurs way lower in the stack like https and encryption at rest.
    - Scalestein 3y ago
      I'm guessing they are thinking of a scenario where SELECT * FROM User_Details gets sent directly to the front end. So even if all you are displaying is the users name or initials you would still be sending things like SSN and credit card number to the front end
      - nerdchum 3y ago
        Sanitizing your inputs is a string issue not a data structure issue. Sanitizing your inputs has been known about for literally almost half a century that should just be default for developers at this point.
        3y ago
mettamage 3y ago
I think he's just rebelling a bit against the culture of caring about scale and performance. A culture that has been pushed out by FAANG that also has some academic undertones. The subtext he's giving is: it doesn't really matter. That's what I read into it, because that's what I identify with. I've met so many fellow CS students (back in the day) who cared about performance optimization. I never cared. I just wanted it to be simple, working and done. I cared about clean code because I had a hard time understanding anything else. I felt allergic to over-engineering because it portrays a whole host of thoughts/emotions that just hurt my brain empathizing with it how it would feel if I'd have those. So I kept things simple too. Usually the repercussions aren't really there. When they are there, then they need to be there and it's usually a sign that your product and the place in the market you're at is evolving. Code is a living thing. Sometimes a big rewrite is necessary, but if that simple unoptimized code held up for 10 years (which is what I'm experiencing), then I'd argue that's okay.
- mjr00 3y ago
  A lot of these things aren't about scale and performance, but maintainability. Once you get over the initial learning curve, things like static typing, Docker, cloud services managed with Terraform, etc. don't require that that much up-front effort and save you a lot of time in the long-run.
ChrisMarshallNY 3y ago
This appears to be someone railing against these practices, but in terms of "defending" them. Some are universal, but some, only apply to certain domains. I'm not really a fan of tearing down others, but I do feel the industry has a lot of room for improvement. Not sure if these types of screeds will actually make things better, though.
2devnull 3y ago
No SQL? It’s satire.
PugPaladin 3y ago
I read this as childish frustration directed at people that are not "as smart" as the author. Regardless of what he's trying to say, there are much much better ways to present these topics.
hsn915 3y ago
OP here. I was working on a feature for a webapp that I thought should be doable in a day, but I spent roughly a week on it. When I was done with it, I looked back and thought: wait, why did this take me the whole week? I couldn't come up with a satisfying answer. So I just decided to accept that I'm not that productive. Maybe there are things I can do to improve my speed of implementing features, but for the time being, this is my speed. I was going to make a writeup about coming to terms with that. But somehow as I was writing (originally on Twitter) I linked it in my head to the way I hate modern dev culture: the docker and the webpack, etc. Programming is already hard, why make it 10x harder with all the tools that require complex configurations, etc? I remember raising this point on HN and other places with other developers, and that there was always push back from people who swear by these tools. So it clicked in my head: I hate these tools because I'm already slow as it is and I can't take it when these complexities slow me down even further. Then as I spent more time thinking about the content, I thought this a manifesto worthy content. But in terms of the points mentioned: I'm dead serious about all of them. Although what I actually mean might not be obvious from first glance. When I said I write objects as-is, it appears that most people in this thread thought I'm writing individual files. This is not what I'm doing. I'm using a B-Tree backed key-value store and doing binary serialization. I also have a scheme where I make use of the properties of B-Trees to make indexing/querying possible. I have a whole write up about this topic: https://hasen.substack.com/p/indexing-querying-boltdb https://hasen.substack.com/p/indexing-querying-boltdb For using HTTP as a medium for RPC, I also have a writeup: https://hasen.substack.com/p/automagic-go-typescript-interface https://hasen.substack.com/p/automagic-go-typescript-interfa... These alternative techniques took time for me to develop, so you could say that it would have been faster for me to just use postgres/docker/aws etc (the standard stack). But this is my point: I really am too stupid to learn them.
- pm 3y ago
  There are plenty of reasons why something you think should take a day might take a week. We often (fallaciously) assess a problem as "easy" without considering the context in which it has to be incorporated, i.e. the codebase. The duration is moreoften a function of the complexity of the codebase, rather than the complexity of the isolated problem.
- 3y ago

by mcv 3y ago

mjr00 3y ago

> I can't tell if this is an honest call to keep things simple, or if it's meant to ridicule that idea. Me neither. All of these things involve tradeoffs. Multiple repos vs monorepo highly depends on your organization. Microservices vs monolith has been discussed to death. A simple, locally-driven deploy process is great for solopreneurs but doesn't scale to full companies. Load balancers might be required depending on your availability requirements. Storing all your data on disk is easier than maintaining a database, but aside from performance bottlenecks, it's harder to define a recovery process (RTO/RPO) in the case of a hardware failure. And as much as I dislike them, there are ease-of-use benefits in using dynamically-typed languages. The biggest technical challenge in most software engineering roles today is evaluating the pros and cons of these types of choices and choosing the right one for your situation.

nerdchum 3y ago
Yeah this is a sane take. Completely agree except for I think theres more performance bottlenecks with a database than files on disk no?

madeofpalk 3y ago

Skeptical of the person who is "not smart enough to figure out docker", yet is smart enough to know about building a "web application into a self contained statically linked binary executable file". I think they are smart enough, they just don't want to, or don't see the value in it (even if they've made an uninformed decision)

mcv 3y ago
Yeah, I'm not smart enough to figure out either. I'm smart enough to rely on the command line tools provided by the framework I'm using.
onion2k 3y ago
If you take 'figuring out Docker' as an open-ended problem then it makes sense. Getting an app running in a container is relatively easy, but that isn't really 'figuring out Docker'. That's just scratching the surface. Learning how to optimize that container, make it secure, put it in a registry so you can reuse it, etc means there's a lot to get through before you can say "I've got Docker figured out." There's no 'Done' when it comes to learning Docker. That makes it a harder problem in many people's opinions.
- bbor 3y ago
  Idk this person claims they “can’t” figure out HTTP verbs and REST. I’d say there’s a very good chance “figure out docker” means “run a program in a container”
foobarbecue 3y ago
Yeah, how does one do this? I see something called bakeware that does it for elixir... Is that what the author is using?
- creshal 3y ago
  Golang makes it very easy, e.g.
- girvo 3y ago
  Nah they just use Go, so they get that outcome mostly for free, based on their other blog posts anyway.
duhsuh90 3y ago
Many doctors watch videos at 1.5X speed or they can not take in the information. If its too slow their brain switches off. I find I have this problem too and i havent figured out docker either even though im a ninja at programming.

jamil7 3y ago

Yeah, I really can't tell if it's satire. Especially things like this: > I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer. OK, well then you might need to gather a little more work experience and meet the repercussions of decisions like this one. Or maybe the OP is a contractor and never has to deal with the repercussions of their actions.

HideousKojima 3y ago
And they'll also run into major liability issues when they leak customer credit card information, SSN, or something similar because they have a single class that represents the table in the database and they use it in both the frontend and backend.
- nerdchum 3y ago
  how does the "structure" of the data have anything to do with leaking information? Seems like data protection occurs way lower in the stack like https and encryption at rest.
  - Scalestein 3y ago
    I'm guessing they are thinking of a scenario where SELECT * FROM User_Details gets sent directly to the front end. So even if all you are displaying is the users name or initials you would still be sending things like SSN and credit card number to the front end
    - nerdchum 3y ago
      Sanitizing your inputs is a string issue not a data structure issue. Sanitizing your inputs has been known about for literally almost half a century that should just be default for developers at this point.
      - 3y ago

mettamage 3y ago

I think he's just rebelling a bit against the culture of caring about scale and performance. A culture that has been pushed out by FAANG that also has some academic undertones. The subtext he's giving is: it doesn't really matter. That's what I read into it, because that's what I identify with. I've met so many fellow CS students (back in the day) who cared about performance optimization. I never cared. I just wanted it to be simple, working and done. I cared about clean code because I had a hard time understanding anything else. I felt allergic to over-engineering because it portrays a whole host of thoughts/emotions that just hurt my brain empathizing with it how it would feel if I'd have those. So I kept things simple too. Usually the repercussions aren't really there. When they are there, then they need to be there and it's usually a sign that your product and the place in the market you're at is evolving. Code is a living thing. Sometimes a big rewrite is necessary, but if that simple unoptimized code held up for 10 years (which is what I'm experiencing), then I'd argue that's okay.

mjr00 3y ago
A lot of these things aren't about scale and performance, but maintainability. Once you get over the initial learning curve, things like static typing, Docker, cloud services managed with Terraform, etc. don't require that that much up-front effort and save you a lot of time in the long-run.

ChrisMarshallNY 3y ago

This appears to be someone railing against these practices, but in terms of "defending" them. Some are universal, but some, only apply to certain domains. I'm not really a fan of tearing down others, but I do feel the industry has a lot of room for improvement. Not sure if these types of screeds will actually make things better, though.

2devnull 3y ago

No SQL? It’s satire.

PugPaladin 3y ago

I read this as childish frustration directed at people that are not "as smart" as the author. Regardless of what he's trying to say, there are much much better ways to present these topics.

hsn915 3y ago

OP here. I was working on a feature for a webapp that I thought should be doable in a day, but I spent roughly a week on it. When I was done with it, I looked back and thought: wait, why did this take me the whole week? I couldn't come up with a satisfying answer. So I just decided to accept that I'm not that productive. Maybe there are things I can do to improve my speed of implementing features, but for the time being, this is my speed. I was going to make a writeup about coming to terms with that. But somehow as I was writing (originally on Twitter) I linked it in my head to the way I hate modern dev culture: the docker and the webpack, etc. Programming is already hard, why make it 10x harder with all the tools that require complex configurations, etc? I remember raising this point on HN and other places with other developers, and that there was always push back from people who swear by these tools. So it clicked in my head: I hate these tools because I'm already slow as it is and I can't take it when these complexities slow me down even further. Then as I spent more time thinking about the content, I thought this a manifesto worthy content. But in terms of the points mentioned: I'm dead serious about all of them. Although what I actually mean might not be obvious from first glance. When I said I write objects as-is, it appears that most people in this thread thought I'm writing individual files. This is not what I'm doing. I'm using a B-Tree backed key-value store and doing binary serialization. I also have a scheme where I make use of the properties of B-Trees to make indexing/querying possible. I have a whole write up about this topic: https://hasen.substack.com/p/indexing-querying-boltdb https://hasen.substack.com/p/indexing-querying-boltdb For using HTTP as a medium for RPC, I also have a writeup: https://hasen.substack.com/p/automagic-go-typescript-interface https://hasen.substack.com/p/automagic-go-typescript-interfa... These alternative techniques took time for me to develop, so you could say that it would have been faster for me to just use postgres/docker/aws etc (the standard stack). But this is my point: I really am too stupid to learn them.

pm 3y ago
There are plenty of reasons why something you think should take a day might take a week. We often (fallaciously) assess a problem as "easy" without considering the context in which it has to be incorporated, i.e. the codebase. The duration is moreoften a function of the complexity of the codebase, rather than the complexity of the isolated problem.
3y ago