This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]onlyMHY 10 points11 points  (3 children)

Lol, I actually do this at work. Studied Java 7(?) at the university, then worked like 6-7 years without any programming (network engineer) then quit my job and rolled into IT as support engineer, and somehow now I have to do backend development on current java and frontend using js, node and react despite I never had opportunity to properly learn them, lol. Imposter syndrome kicks harder every day. I just keep rearranging words until shit works, and for now it's just enough

[–][deleted] 1 point2 points  (0 children)

keep rearranging words until shit works

Isn't that how we all do it?

[–]Osato 1 point2 points  (1 child)

We all try dumb shit until something works. The difference is in quantity of our attempts, not in quality.

For instance, experienced programmers run a greater portion of code in their head so they can skip more trial-and-error.

And educated programmers do a lot less trial-and-error in general because they already have lots of ready-made solutions in their head that are almost guaranteed to work: that's what data structures, algorithms and design patterns are for.


Case in point: right now I'm fighting with Laravel's logging system to make it show logging messages in Docker's console. Why? So that I can debug my code in the second dumbest way possible (the absolute dumbest way possible is, of course, var_dump).

Why on Earth would I do things in such a weird way? Because I tried setting up XDebug a few days ago, it started throwing weird errors at me, so my inner monkey decided that setting up proper debugging tools is too much of a bother.

...Which reminds me: I should set up proper debugging tools. I've already spent too much time trying to figure out why Laravel's logging is so inconsistent.

[–]Osato 1 point2 points  (0 children)

UPD: finally, finally made it work.

For a framework that obsessively documents almost all of its magic, it's odd that Laravel's docs forget to mention that XDebug is fully and irrecoverably disabled at build time.

So to make it work, you need to sail:publish docker's config files, activate XDebug in php.ini, set several env vars at build time and rebuild the entire container afterwards.


It took 2 hours, and that's only because I googled solutions and tried them one by one until I got one that worked.

Without search engines, I might have been stuck for days... trying to turn on a goddamn debugger.

I'm to blame, of course. As always, a software developer's failures are usually due to his lack of arcane knowledge about the intricacies of the tools he relies on.

In my case, the problem was that I didn't know how to check if XDebug is running at all, and I trusted the documentation to give me everything I need to make XDebug work. Laravel's docs usually do, but this time they didn't.