|
|
|
|
|
|
by majewsky
1454 days ago
|
|
|
> Yesterday was for me like disaster. I worked until 22 o'clock, (I had to stop at 17 o'clock) to find out that I'm running a microservice in a Docker Container and the changes I made on a mail template had no effect, when I send them, since I was working on local files. I am a senior IT architect with 10+ years of industry experience. Just this Friday, I was debugging an issue in a Docker image together with a colleague, and we were completely baffled why none of our debug output was showing up when we ran the test job in the CI on the Docker image. After half an hour, we realized that we had been pushing the image into the wrong repo, so the CI never picked up the changes. It happens to everyone. Don't sweat it. > From now on, I will reading the docs more and not trying hunt the exact answer on stackoverflow at first place. When mentoring, I always encourage my juniors to take time out of their workday to just read up on things. If you're going to have to use a difficult new library, give yourself an hour or two to just read the documentation on that library to understand the principles on which it is based. Even if you don't have any specific new technologies lined up, maybe take the time every once in a while to just read a random manpage. You don't have to memorize everything in there, but just getting a vague comprehension of what all these tools that you use are actually capable of. Once you run into a situation where these capabilities can be useful to you, you might just remember reading about it somewhere, find the relevant part in the manpage, and save yourself some time hunting on SO. |
|
|
Some documentation is a bit large for this, but less than you think because it gets faster with practice.
I'd also mention "don't be afraid to source dive on OSS stuff", you'll be slow at first but being able to jump into other's people code and mentally reverse engineer their intent/architecture grows with time and is also a superpower.
(to the point where I often read the code first then check the docs and/or the tests to see if what I plan to do is explicitly supported or just incidentally going to work)