Hey guys, i’m a junior working at a company, i feel very uncomfortable when my task is to find a scale issue, too many times i took much time to figure out what is happening, do you guys have any tips to learn more about that? People always say “this come with the time” but sometimes i get frustrated trying to find a problem and sometimes it is right in front of me. Any tip will be very appreciated!
Unfortunately that is the nature of the job - there is a lot of discomfort around debugging issues in any tech path and there is no easy answer to a single problem as each one will be unique even if it is the same issue but presenting in a different way.
The best thing I have learned to do to deal with this is build up a general checklist of things to go over when an issue occurs. This does take time though as this list will be specific to the task at hand and even to the company you work for.
I would say don’t stress about finding the answer straight away, these things take time and who ever has set you this task should be aware of that, if they aren’t then make them aware.
If the solution is under your nose and you don’t realise it straight away, then that is a new thing learned and another thing to put on your check list the next time something goes wrong.
1 Like
Thanks for your tip, sometimes i charge myself a lot because of stuffs like that, i’m glad to hear that is part of the job, i have around a year of experience, i leanerd too much in this time, when i find someting that i have difficult i just get anxious to reach the level that this won’t be a huge problem or take too much of my time. And also the check list thing is a great idea, i have some check lists but for personal goals, never did one for my hardest difficulties, i’ll start doing that!
The essence of techart is just poking at stuff to see how it works and how it can be made better. Very few of us started off as great programmers or expert mathematicians – we started by getting interested in the tools., then we got angry about how clunky the tools could be, and finally we started finding ways to make them better.
Starting at stuff you don’t understand and saying why is it like that? is a big part of the job. It does get easier as you get a more and more solid understanding of what is and is not possible with the math and programming tools we have.
The key thing to remember is there’s no shame in not knowing the answer right away! Asking around is a key tool for making yourself better – just be sure it doesn’t cross the line between “help me understand this” and “please do my work for me!”
Keeping notes can help a lot – you won’t always find the answer in your notes but often the act of note-taking helps you think things through clearly and lodge in your memory. And a checklist is a great idea – eventually you’ll do it by instinct but for now, it forces you to be thorough and it is something you can add too over time as you learn more and more weird ways for problems to arise.
The next step after you get the checklist is to turn it into tool or set of tools you can use to do things automatically – that’s a great way to learn to be a better TA .
2 Likes
Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, by David J. Agans. author’s site is an excellent and easy read. Even though I read it, maybe 20 years ago, I still get stuck and refer back to it.
All the other advice is spot on. How I personally implement some of it is a personal wiki via markdown files, (that I also keep in source control). Interesting stuff, weird bugs (and hopefully their fixes) stuff to investigate and more all goes in there. For example, I have file for all Qt/PySide stuff and it gets used like a personal Stack Overflow, by me, for me. I always check it first before the internet at large, and if I do have to search the internet, I’ll add that answer and make a code snippet to fit my use case. I’m constantly adding to it, tidying and reviewing.
While I do type a lot of notes, I also often write, by hand, to help get through a problem. Sometimes the clarity brought from writing it down is enough and sometimes being able to quickly write an idea with a little sketch (and iterate) is where the magic is. Sometimes this is just scaffolding I discard but sometimes I’ll take a pic and note it in my wiki.
Persistence and incremental improvements are how most things happen, and then write things down so you don’t forget.