Indentation and breaking things into smaller segments. Makes it easier for not only me to follow but for anyone else who might want to have a look at my code can easily navigate thorugh the 100s of lines of code.
It is important because not only is your work public (anyone can inspect and have a look) but this industry require a lot of collaboration and peer reveiew. There is no point in writing code in a way that no one else can follow, understand or work with.
Extremely!, in this industry we often work with a large group of people on a project so we have a responsibility not only to the computer that is running our program, but to pretty much every body else who will be using our code as well. I cant even imagine checking out someone's DOM to find what I found in the zen garden exercise... Made me so dizzy that I felt a bit sick.
Tabs, less button ressing and a nice amount of readable space.
My work space is tidy and so is my code (considering my level of expertiese at the moment).
My downloads folder, however, is not. Although I never keep anything in there that I actively need, its contents are there for reference.
```
function testSum(){
```
function sum(a, b){
}
I would prefer to use TDD. I find it easier (clarity-wise) to compartmentalise the big picture into smaller parts and outlining what I want out of things first before finding out what I actually need to do to get there. I feel that UT is more prone to mistakes if you are at my level (which is total noob) despite having the benefits of knowing exatly where went wrong but not why. I would rather answer a why question than a how one.
We can begin with TDD and working backwards into UT. TDD will give us the frame work and the basic answers to our question while UT can be used to fine tune for more complex problem when we star building on the code to fulfill the bigger picture.
I thought that looks like fun. I felt like I could learn better using the testing method as it would not only get me used to using and understanding functions but gain a basic understanding of what I should EXPECT the code to do.
I like the interface. I like the feel of having someone walk you though set up (the typing word for word greeting) and how they have used a computer program but make it feel like it was actually a person on the other side was cool. I struggle with my compueter at the moment as it is very old and does not like to do more than one thing at once. The fact that I can have one place where I can see where I'm working from, where I can steal from, what I'm doing now and what I can get out of it immediately in just one place is pretty magical.
I'm sure it will confuse me in due time but at the moment I'm finding it useful. Its quite a straight forward thing that is easy to follow even for total beginners like me.
"REPLIT"... I hope that is actually what it is cause otherwise it would be the whole how do you pronounce "anitipodes" all over again.
The rubber ducking technique! Because I already talk to myself regualarly to help me organise my thoughts anyway... and definitely Pseudocoding, being able to break things down in plain english into smaller steps will help me figure out what I have to do next.
As mentioned before I already practice rubber ducking without the rubber duck. I will probably have to aquire a rubber duck at some stage to actually use the rubber ducking technique. Right now my partner is standing in for the rubber duck (P.S. I also wanted to see how many times I can say rubber duck before someone gets frustrated.).
Like drawing a wire frame for my blog I till use Pseudocode to start off my process steps by step, if I dont know how to actally achieve some of the points I have written then I will do some research/ask for help before getting started so that I have a clear path to follow. Rubber ducking will be used for on the spot trouble shooting.
I'm guessing this was a warm up as it felt easy to understand and workthrough despite my lack of experience with JavaScript.
Yes, It gave me the best guidelines as to what it actually wanted to output. The error messages were useful only during debugging.
WHEN IT WORKED!
Neither as I tended to use both throughout. The instructions gave me a rough idea of what I needed to work towards and the tests showed me what it wanted. The outputs were most useful while debugging like the last kata.
Finding out what the correct function to use for replacing the numbers for its respective string.
It was useful as an anchor. Everytime I got frustrated I looked back to see what my real objective was before trying something new again or pushing on to another aspect of the code. In the end I asked for help from a friend on slack who pointed out that I had some technical errors. Thank god.... Thought I was completely inadequate up until that point.
The differences in referencing objects for sure. Took a while to understand why . couldnt be used in functions but [ ] for strings could. The readings did help but the slight lack of examples made it hard to understand until I actually say what the problem was myself in Repl.it.
Yes, many times after the initial was written out according to the steps given on github. There is nothing that I'd like to change as it is already quite a small set of code... Except for maybe no so many spelling mistakes and calling errors this time.
I would say 3 as they were easy to understand but inorder to build the functions around the use of these methods required a bit of understanding and research.
Definitely MDN JavaScript References. The examples are simple but shows exactly what kind of things are expected in the code inorder to be able to use them properly. W3 was also quite useful but not as easy to undertsand at first glance. We don't even want to talk about stack overflow.... too many people working on much more complicated projects than us.