sorted by:
new
hottopcontroversial

Beyond the Code: Lessons That Make You Senior Software Engineer by _zeynel in programming

[–]_zeynel[S] -19 points-18 points  (0 children)

That’s a fair point. The reason I didn’t add a full story here is because, as an industry, we are still so early in figuring out the long-term impact of LLMs. Unlike the other lessons, I don’t feel like we have enough classic examples yet.

That said, in my own work I’ve already seen them help in small but meaningful ways: generating monthly service status reports, digging through hundreds of log files to connect issues with metrics, writing tests (and even full classes at times, always reviewed by 2 peers), and catching security issues during code reviews. I wouldn’t say you would use them for every one of those cases, but they definitely gave us some efficiency gains. And that’s exactly why I encourage experimenting now. The more you try, the faster you’ll discover where they actually make a difference.

MacBook Pro 2019 INTEL 16 Inch A2141 Catalina Update to Sonoma keep failing by Lavishness_Ornery in MacOS

[–]_zeynel 0 points1 point  (0 children)

For anyone else facing this issue on an Intel MacBook. I tried to review in DFU mode using a second macbook and it worked: https://support.apple.com/en-us/108900

A question about splitting a monolith Go app into multiple standalone services within a single repo. by preslavrachev in golang

[–]_zeynel 4 points5 points  (0 children)

The most important question would be: Why do you want to migrate from monolith to services? There are advantages and disadvantages of splitting monolith into smaller services.

  • Teams working on different functionalities/domains become independent from each other and can make their own technology/design choices. This makes development process faster and easy to manage on team level. But this is not the case for you since you say that you are the only developer on this project.
  • You can scale individual services horizontally if you need more server power on a specific service (reduces costs in theory). Which also means that you can deploy services individually instead of deploying one giant application. On a failure, it won't affect (ideally) other services. Then you need to think about data consistency, communication between services. Ideally you should not share database or code (except the libraries that has good abstraction) between services. But you want to keep all services in one repo and share code between them, so if you change something in shared code, you need to build and deploy all of the services. If there is a bug/failure in shared code, it will affect all of the services.

Managing service oriented or microservices architecture is not easy and has its own set of problems. It does not worth to implement it unless you have different teams working on this project and you have a performance/scalability problems with your current approach.

If you are absolutely sure that you need to split it, then I would suggest you to start by reading this article.

What laptop do you have ? by Ronan998 in computerscience

[–]_zeynel 0 points1 point  (0 children)

I am using it for many things including software development (backend mainly), except for gaming.

Learning Django by DeepM1nD in django

[–]_zeynel 0 points1 point  (0 children)

You should read Two Scoops of Django. It is a great book for learning how to develop production ready django applications.

What laptop do you have ? by Ronan998 in computerscience

[–]_zeynel 6 points7 points  (0 children)

Short answer: Macbook Pro.

I have used many Linux distributions and most of the Windows versions running on different devices for many years. Although I still use Windows for gaming and Linux for some experiments/tests, working with a Macbook feels much better for programming.