Debugging
- A lot of bigger companies code heavily with design patterns which have the downside of making debugging more difficult. It’s not uncommon to find yourself jumping down call stack node to call stack node all the way down the rabbit hole to the api call. Just to see what endpoint was used.
To make this easier.
- Take notes of the call stack. It’s easy to lose track of the call stack and it is nice to be able to jump to different places in the code base. Alternatively, you can use the new Xcode feature called bookmarks.
- Often “Clean Coders” Will heavily rely on protocols. Sometimes they are used more than once, sometimes they aren’t. Also sometimes developers use the same function names for different methods, with the only signature differences being the arguments. That makes it difficult to search the codebase, as you will keep seeing the wrong methods popup in your searches. Also if someone used a protocol type for a property and a method is called on that property, then you will have to go through the trouble of trying to find when the protocol typed properly was assigned to try to get an idea of what its concrete type is at runtime. This is a pain in the butt. The alternative is to `po type(of: <protocolInstance>)` and this will print out the conrecte runtime type you are looking for. Which sucks to have to do it at run time, but it is what it is with the “design pattern” worshipers.
- Using print statements can be easier too. Also when you code try to keep shallow stack traces. More on that here.
- Create a reminder at the beginning and ending of your work day which has a url for your google sheet that tracks your daily activities for self evaluations and scrum updates.
- Rehearse everything especially when you start learning anything. Figure out ways to rehearse or internalize the information. You will be exposed to a lot of new information at every job. For example you might have to jump through a few hoops when authenticating with your vpn. So authenticate 25 times in a row, so that you start your day with a second hand behavior instead of wasting your cognitive capacity.
- Focus on choosing diverse jira tickets and stories so you have a wide number of experiences as quickly as possible.
- Write notes, medium articles, and the likes so that if someone needs help you can pass around your documentation instead of having to join a meeting, though a meeting might be more appreciated. So perhaps both is the most impressive and the documentation can be useful in case you forget. Also, rehearse everything you have to write documentation for.
- Hire (potentially a principal engineer in India) or recruit a mentor experienced in the position you are hired for to meet daily after work when you start and weekly once you are in the flow of things. This is an opportunity to candidly talk about your work day, parts that flowed, parts that didn’t. It’s also an opportunity for you to “air out” important thoughts you might be taking for granted.
