[DiscordArchive] The argument emulator developers always use against scripting is performance, but performance is not
[DiscordArchive] The argument emulator developers always use against scripting is performance, but performance is not
Original source
The argument emulator developers always use against scripting is performance, but performance is not a major factor until you are trying to scale for thousands of players. What's better, profiling and fixing performance issues when they happen, or never actually getting to a finished releasable project?
rektbyfaith
11-15-2021, 10:09 AM #1Archived author: stoneharry • Posted: 2021-11-15T10:09:38.790000+00:00
Original source
The argument emulator developers always use against scripting is performance, but performance is not a major factor until you are trying to scale for thousands of players. What's better, profiling and fixing performance issues when they happen, or never actually getting to a finished releasable project?
Original source
Same deal with junior developers in the workplace, they always want to write the best code in the world but business moves fast and it's often better to just have something that works. Context is key though, obviously there are use cases where it's better to take things slow and well designed, implemented, and tested
rektbyfaith
11-15-2021, 10:12 AM #2Archived author: stoneharry • Posted: 2021-11-15T10:12:16.062000+00:00
Original source
Same deal with junior developers in the workplace, they always want to write the best code in the world but business moves fast and it's often better to just have something that works. Context is key though, obviously there are use cases where it's better to take things slow and well designed, implemented, and tested
Original source
That's why the general security sucks tho
rektbyfaith
11-15-2021, 10:14 AM #3Archived author: Thanathros • Posted: 2021-11-15T10:14:49.206000+00:00
Original source
That's why the general security sucks tho
Original source
The fast "it just works" approach is hazardous to actual quality
rektbyfaith
11-15-2021, 10:15 AM #4Archived author: Thanathros • Posted: 2021-11-15T10:15:10.462000+00:00
Original source
The fast "it just works" approach is hazardous to actual quality
Original source
It shouldn't impact security. There's a general rule of thumb: pick two of speed, cost, and quality.
Sacrificing quality shouldn't mean things like security are sacrificed, it should just mean less maintainable code or more technical debt. It's not necessarily a bad thing when weighed up against the other costs
rektbyfaith
11-15-2021, 10:17 AM #5Archived author: stoneharry • Posted: 2021-11-15T10:17:13.231000+00:00
Original source
It shouldn't impact security. There's a general rule of thumb: pick two of speed, cost, and quality.
Sacrificing quality shouldn't mean things like security are sacrificed, it should just mean less maintainable code or more technical debt. It's not necessarily a bad thing when weighed up against the other costs
Original source
In my opinion "doing it right" mentality is a bell curve.
Juniors? Anal about doing it "right" often to the detriment of getting stuff out of the door and fussing over minor things that can be tech debted away later.
5 years on the job and think they know what's best? Start slacking and rushing and getting things out the door faster.
10 years? You've broken enough things by being that lax and it's bitten you on the arse enough you go back to doing it right.
rektbyfaith
11-15-2021, 10:18 AM #6Archived author: Deleted User • Posted: 2021-11-15T10:18:46.611000+00:00
Original source
In my opinion "doing it right" mentality is a bell curve.
Juniors? Anal about doing it "right" often to the detriment of getting stuff out of the door and fussing over minor things that can be tech debted away later.
5 years on the job and think they know what's best? Start slacking and rushing and getting things out the door faster.
10 years? You've broken enough things by being that lax and it's bitten you on the arse enough you go back to doing it right.
Original source
There's generally a _reason_ standards and best practices come about.
rektbyfaith
11-15-2021, 10:18 AM #7Archived author: Deleted User • Posted: 2021-11-15T10:18:58.157000+00:00
Original source
There's generally a _reason_ standards and best practices come about.
Original source
It's a very fine line. One that I think needs someone to actually work on larger scale software projects in a business environment to fully grasp.
rektbyfaith
11-15-2021, 10:19 AM #8Archived author: Deleted User • Posted: 2021-11-15T10:19:35.069000+00:00
Original source
It's a very fine line. One that I think needs someone to actually work on larger scale software projects in a business environment to fully grasp.
Original source
Context is key for everything, it is a fine line to tread. I quite like the modern fad of microservices even if it does add a whole lot complexity and doesn't provide value often. It forces you to write strong APIs and if something isn't working, in theory you should be able to throw away the code and write it from scratch using the same tests
rektbyfaith
11-15-2021, 10:20 AM #9Archived author: stoneharry • Posted: 2021-11-15T10:20:46.608000+00:00
Original source
Context is key for everything, it is a fine line to tread. I quite like the modern fad of microservices even if it does add a whole lot complexity and doesn't provide value often. It forces you to write strong APIs and if something isn't working, in theory you should be able to throw away the code and write it from scratch using the same tests
Original source
Context absolutely is key and going too rigid into doing it "right" will have it's own major bottlenecks.
rektbyfaith
11-15-2021, 10:21 AM #10Archived author: Deleted User • Posted: 2021-11-15T10:21:25.342000+00:00
Original source
Context absolutely is key and going too rigid into doing it "right" will have it's own major bottlenecks.
1 Guest(s)
1 Guest(s)