Hmmmm... doing vs. knowing. Well there's a fun one. It's obviously a false dichotomy; to do you need to know, and to know you need to do. I'll have a crack at understanding your particular problem.
I know how to make them work, or at least I can tinker until they do
and
Typically this involves google and a lot of trial and error
This sounds a bit like you're at a level of development experience which I've seen before. Talented people who 'can make it work'... eventually. If they have enough time they'll keep changing the code until it does what they want. Then, when it's working they'll push on to the next thing they want to build.
I like to call the first bit flailing - keep typing away until it works. It's definitely doing - but do you know what you're doing? Don't worry too much: most people who write CSS are doing this, so you're in good company.
But you need to get out of this stage, not just because you need to get past an interview, but also because it's better to know what you're doing. You'll get more done, and be able to do harder things.
So... advice.
before fixing something to make it work, have a conversation with someone. Don't have someone? Google 'rubber duck debugging'. Explain what you're going to do and why you think it'll fix things. If it doesn't work, explain why it doesn't work. Get into the habit of explaining.
Say to yourself, out loud if possible, what each line of code in your solution is doing. Is there a bit you don't understand? Google it, read about it.
When you've solved something, explain why it works. Blog about it. If you can explain something in writing it will force you to understand it. Write short posts about what you've learned.
Play with code. Stop trying to get things 'done', instead pull them around a bit to see how they work. Can I do this with a for loop, with reduce, with a class, with a function, as a single expression, with recursion... how many different ways are there? Which do you prefer? Why?
Stop tinkering to make things work. Start tinkering to find out how they work.
Do more katas - coding exercises. Exercism or Code Wars are good. Read other people's solutions.
Go slow. Much slower. Stop trying to be effective and productive, start trying to understand. Slow is smooth, smooth is fast.
Thank you for the insights!!! Those bullets are super helpful. I'm definitely guilty of "done, next" type development! I will try and take your advice. I've enjoyed blogging so far and just began to understand something important on my new project so will write about that soon!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hmmmm... doing vs. knowing. Well there's a fun one. It's obviously a false dichotomy; to do you need to know, and to know you need to do. I'll have a crack at understanding your particular problem.
and
This sounds a bit like you're at a level of development experience which I've seen before. Talented people who 'can make it work'... eventually. If they have enough time they'll keep changing the code until it does what they want. Then, when it's working they'll push on to the next thing they want to build.
I like to call the first bit flailing - keep typing away until it works. It's definitely doing - but do you know what you're doing? Don't worry too much: most people who write CSS are doing this, so you're in good company.
But you need to get out of this stage, not just because you need to get past an interview, but also because it's better to know what you're doing. You'll get more done, and be able to do harder things.
So... advice.
before fixing something to make it work, have a conversation with someone. Don't have someone? Google 'rubber duck debugging'. Explain what you're going to do and why you think it'll fix things. If it doesn't work, explain why it doesn't work. Get into the habit of explaining.
Say to yourself, out loud if possible, what each line of code in your solution is doing. Is there a bit you don't understand? Google it, read about it.
When you've solved something, explain why it works. Blog about it. If you can explain something in writing it will force you to understand it. Write short posts about what you've learned.
Play with code. Stop trying to get things 'done', instead pull them around a bit to see how they work. Can I do this with a
forloop, with reduce, with a class, with a function, as a single expression, with recursion... how many different ways are there? Which do you prefer? Why?Stop tinkering to make things work. Start tinkering to find out how they work.
Do more katas - coding exercises. Exercism or Code Wars are good. Read other people's solutions.
Go slow. Much slower. Stop trying to be effective and productive, start trying to understand. Slow is smooth, smooth is fast.
Good luck!
Thank you for the insights!!! Those bullets are super helpful. I'm definitely guilty of "done, next" type development! I will try and take your advice. I've enjoyed blogging so far and just began to understand something important on my new project so will write about that soon!