Working On Projects

The interns have compiled a list of tips to keep in mind when working on projects. You’ll want to have these in your back pocket as you begin to embark on more ambitious tasks.

Ask Questions

You’ve likely already been told this several times during your onboarding process. However, this can mean different things to different people. There is definitely a proper way to ask questions, so keep these tips in mind when you want to ask for help.

Understand the problem domain

When first starting a project, you will likely have a very vague notion of what you’re supposed to accomplish. Ask questions about what repositories you will need to modify, where the existing functionality you need to build off of is located, and what your end result should look like. Do not attempt to go in to a project without a very clear understanding of what you’re trying to accomplish, as this will result in a lot of wasted time and frustration.

Make an honest effort first

While your co-workers are usually always willing to answer your questions, their time is also valuable. Therefore, it is very important to put in effort in to solving a problem before asking for help. Not only that, but if you are working with tools you don’t understand and you ask a question about how to use them, it is very possible you will get an answer you don’t understand. Try to solve the problem yourself first, then feel free to ask about it.

Know what you’re trying to ask

It may be tempting to ask broad, general questions, like “What does an implicit val have to do with a JsValue?” However, this question has no meaning without the context it occurs in. If you aren’t sure what you are trying to ask, write down what it is you know, what it is you don’t know, and what you are trying to accomplish. Then, do your best to formulate a concise question that has a clear answer without needing to know the specific context of the issue. So with the above example, you would want to figure out what an implicit val is, what a JsValue is, and then ask something closer to “What dependencies do I need to make an implicit val for converting a string to a JsValue?” That question has a pointed answer, where the previous question does not.

It’s also a very good idea to keep notes about the answers you get to your questions. That way, you will not have to ask the same questions multiple times.

Breaks

When working on a longer project, there is a good chance you may get frustrated at some point. Persistence is key. A short break taken to work on break / fix or a smaller issue can help from getting burnt out. However, a long break can be very detrimental to the success of your project. If you are stumped, don’t give up. The longer you stay away from an issue, the harder it is to come back to. From a psychological standpoint, it can be hard to motivate yourself to come in to work if you know you’ve got a seemingly unsolvable issue waiting for you. Don’t let that issue sit. Utilize the tips for asking proper questions, and hack that problem out.

Pairing

Pairing on projects is a great way to learn more and accomplish more. Discussing a problem out loud with someone else can help you think of it in a different way, even if they don’t say anything back. Drawing diagrams, writing the goal out on paper, and discussing with a peer are all ways of getting your brain working from a different angle, which will be a considerable help when trying to finish a project. Beyond the personal benefits of pairing, it is also good for more than one person to have an immediate knowledge of the code you are writing. This can save loads of time if the code needs refactoring, but you aren’t available to work on it.

If you require the assistance of somebody you know has a lot on their plate, it isn’t a bad idea to ping them and ask if they would be free to work with you in a day or two.

If you are jumping in on someone else’s project after they have started, it’s a good idea to look at each individual addition they’ve made (easy to do with Github history) and figure out how those parts fit together.

Don’t take the easy way out

There is a good chance that the code you are working on now is closer to production-level code than anything you’ve worked on before. As a responsible programmer, you cannot cut corners. There is always a quick, messy way to solve a problem, but “With great power comes great responsibility.” Your code will be read by others in the future if refactoring needs to be done, and we want that to be as easy as possible. As you are writing your code, constantly ask yourself “Is this readable?” “Does this cover all possible scenarios?” “Is this easily testable?” Never be afraid to dig in to different libraries and read some code, as you will always learn more this way. Not to mention, the parts we don’t understand fully are where the bugs are hiding.