4 ms·

> What they call "building your own framework" is simply what I think of as programming. If you want an analogy, this is like a builder claiming that he is goi

> What they call "building your own framework" is simply what I think of as programming. If you want an analogy, this is like a builder claiming that he is going to make all bricks and nails himself. You don't usually write your own standard library, why would you write your own framework?

jseban 4y ago
Except it's not like that, software is not standardised, it's custom made. And software engineers already have their toolset. The real analogy would be telling all the builders that they now have to use those shitty multi tools that are 10 screwdrivers and a hammer all in one.
- delusional 4y ago
  The analogy is now officially making the argument less clear
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
- jprd 4y ago
  you are limiting yourself to typing out code, rather than what is amazing about a human brain, the ability to see coherence in random shit and improve it. If you feel your job is to find neat ways of writing Java or C# or wtfever, you are limiting yourself. You should be looking to offload any repetitive/tedious task to automation, and from there figuring out how to leverage ML to make it efficient. The "work" you speak of is going to be obsoleted in the next decade, if it isn't cutting edge CS theory it should be done by the machine.
- cornel_io 4y ago
  For 90% of SWEs (and closer to 99% of anyone doing front-end web stuff) it really isn't that custom. You're not solving problems that are difficult except those which your team creates for themselves by making bad choices as they service the fairly routine and unexciting feature requests that come in from product. And that's not to say that is a bad thing, all teams make bad choices and have to improve them over time, even when they are using highly opinionated frameworks. It's an unavoidable part of software development, even incredible teams and devs need to refactor. The point of using frameworks is that you can be sure that many of the bad choices the people who wrote it made early on have by now been tidied up. You don't have to worry that Dougie the intern's custom HTTP router is actually all sorts of ballsed when you go to set up your first DELETE endpoint, because Dougie didn't get to touch anything that fundamental to the stack. I do get off the boat when it comes to leftpad and stuff like that, don't ever pull external dependencies for trivial things. But an ORM or a UI framework? Those problems have been solved hundreds of times, absolutely no need for anyone to solve them again unless you're that good that thousands will move to using your solution instead of the existing ones.
  - deleted 4y ago
    [deleted]
CuriousCosmic 4y ago
I think there's a very prevalent and very real difference between "building your own framework" and "building your own bricks and nails". Programming isn't exactly equivalent to a construction worker. Rather your team are the construction worker, the structural engineer, and the architect all at once. The framework isn't bricks and nails. It's a prefab house plan. You follow the instructions and you get a house out on the other end. If you need to go outside what the prefab covers, you have to fight the framework because now you are drawing over top of an already printed out structural plan to try and do something different. The equivalent of bricks and nails in SWE is using libraries. Use a library to do a thing. You still need to design the program (drawing the floor plan), formalize how the parts interact (drawing the structural plans), and actually put the pieces together (building the actual house) but you don't need to worry about the small details like how to perform X algorithm (make the bricks), write a messaging standard (make the nails), or handle the intricacies of concurrency, distributed data structures, or drawing to a user interface (making the concrete and mortar). Your libraries do that for you. All you need to do as a developer is focus on writing neat functional kernels that do "the hard stuff", wrapping all your "hard stuff" and libraries together in some OO class to implement a certain functionality, and then stringing the bits together with some imperative glue to tell all the pieces to work together. Past that is orchestration & administration and that's Ops' responsibility. Unless all you need is cookie cutter, don't use a cookie cutter. Fighting the cookie cutter will be far harder than using the tools for the job(cleanly separated, well documented, and interoperable libraries) to solve specific problems.

jseban 4y ago

Except it's not like that, software is not standardised, it's custom made. And software engineers already have their toolset. The real analogy would be telling all the builders that they now have to use those shitty multi tools that are 10 screwdrivers and a hammer all in one.

delusional 4y ago
The analogy is now officially making the argument less clear
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
jprd 4y ago
you are limiting yourself to typing out code, rather than what is amazing about a human brain, the ability to see coherence in random shit and improve it. If you feel your job is to find neat ways of writing Java or C# or wtfever, you are limiting yourself. You should be looking to offload any repetitive/tedious task to automation, and from there figuring out how to leverage ML to make it efficient. The "work" you speak of is going to be obsoleted in the next decade, if it isn't cutting edge CS theory it should be done by the machine.
cornel_io 4y ago
For 90% of SWEs (and closer to 99% of anyone doing front-end web stuff) it really isn't that custom. You're not solving problems that are difficult except those which your team creates for themselves by making bad choices as they service the fairly routine and unexciting feature requests that come in from product. And that's not to say that is a bad thing, all teams make bad choices and have to improve them over time, even when they are using highly opinionated frameworks. It's an unavoidable part of software development, even incredible teams and devs need to refactor. The point of using frameworks is that you can be sure that many of the bad choices the people who wrote it made early on have by now been tidied up. You don't have to worry that Dougie the intern's custom HTTP router is actually all sorts of ballsed when you go to set up your first DELETE endpoint, because Dougie didn't get to touch anything that fundamental to the stack. I do get off the boat when it comes to leftpad and stuff like that, don't ever pull external dependencies for trivial things. But an ORM or a UI framework? Those problems have been solved hundreds of times, absolutely no need for anyone to solve them again unless you're that good that thousands will move to using your solution instead of the existing ones.
- deleted 4y ago
  [deleted]

CuriousCosmic 4y ago

I think there's a very prevalent and very real difference between "building your own framework" and "building your own bricks and nails". Programming isn't exactly equivalent to a construction worker. Rather your team are the construction worker, the structural engineer, and the architect all at once. The framework isn't bricks and nails. It's a prefab house plan. You follow the instructions and you get a house out on the other end. If you need to go outside what the prefab covers, you have to fight the framework because now you are drawing over top of an already printed out structural plan to try and do something different. The equivalent of bricks and nails in SWE is using libraries. Use a library to do a thing. You still need to design the program (drawing the floor plan), formalize how the parts interact (drawing the structural plans), and actually put the pieces together (building the actual house) but you don't need to worry about the small details like how to perform X algorithm (make the bricks), write a messaging standard (make the nails), or handle the intricacies of concurrency, distributed data structures, or drawing to a user interface (making the concrete and mortar). Your libraries do that for you. All you need to do as a developer is focus on writing neat functional kernels that do "the hard stuff", wrapping all your "hard stuff" and libraries together in some OO class to implement a certain functionality, and then stringing the bits together with some imperative glue to tell all the pieces to work together. Past that is orchestration & administration and that's Ops' responsibility. Unless all you need is cookie cutter, don't use a cookie cutter. Fighting the cookie cutter will be far harder than using the tools for the job(cleanly separated, well documented, and interoperable libraries) to solve specific problems.