IMHO, the thing that new programmers really struggle with is learning how to break a problem down into the steps their language allows them to express. Lots of people have never had to logically think out and algorithm to do simple things and it takes them lots of practice to understand how to do that.
For example, suppose I'm a new programmer given the notional task of making a program to make me a sandwich, can I just:
makeSandwich();
and be done with it?
Or do I need to break it down to the n-th degree?
//make bread
bread=harvestwheat();
bread=millwheat();
bread=bread+water;
//and so on
is that the right way to even make bread? Or do I already have bread I can work with someplace?
Or do I need to do something else? Maybe this particular programming environment doesn't need me to make bread, but I have to transform a milk object into butter for some reason that seems entirely random to the new programmer. Who knows? Lots of the things that we take for granted seem entirely arbitrary to the new programmer and learning to break a problem down in a way that maps to the environment is a very hard problem to learn to solve repeatedly.
edit in a way this is a common topic even on HN with the "do x in n number of line" posts that are common.
Here is a methodology that I recently started using:
Describe, at high level, what needs to be done to make a sandwitch, in your head. Then write code that looks exactly like what you said in your head, as much as possible. Dont worry if it turns out to be impossible to implement that way - you can always tweak it later until it becomes possible. Just try to make sure it reads more or less clearly.
Repeat with each of the steps, checking whether there already is a library that does that for you.
function makeSandwich() {
var breadSlices = getBreadSlices(2);
var ham = getHam();
var butter = getButter();
var butteredSlice = spread(breadSlices.first(), butter);
return foodPile(butteredSlice, ham,
cheese, breadSlices.last());
}
Continue the same way with getBreadSlices, getHam, getButter, pile.
As you progress this way, you'll notice that you'll be able to implement some processes in terms of more generic functions (e.g. spread and foodPile).
You'll also notice that you need an environment (macro, such as kitchen, or micro, such as frying pan) to temporarily place stuff that you're working with, while you wait for some process to complete. Thats when you start creating classes and objects that represent this environment.
I know it's a bit silly but the thing that jumped out about your comment and the parent comment is the butter. You butter a hame and cheese sandwich? Is this a cultural thing I'm not familiar with? zooms off to google to check
I moved from the US to Ireland a year ago, and while I love it here the constant vigilance against sandwiches slathered in mayonnaise and butter can be exhausting. I go to the sandwich shop and they helpfully ask "Butter or mayo?" - to which I respond "mustard", and immediately reveal myself as an outsider.
I thought garlic fries, like the sort at Giants games, were delicious! Some garlic, olive oil, parmesan, etc. I was shocked to discover that here and in the UK garlic chips consist of chips (fries) with garlic-accented mayonnaise spread all over them.
And don't call it Aoli. That's just dressing up a disgusting condiment with a fancy word.
I live in the UK, and the thing I thought summed up the British and Irish obsession with mayonnaise best was when I recently bought a hoi sin duck wrap at the local Tesco and it had "No mayo" in big letters on the front, as if the lack of may was something highly unusual and/or edgy.
Since then I've looked at the ingredient list of every other product with great suspicion, expecting to find mayo everwhere...
I'm not an outsider, yet I always answer "no thanks".
I use butter and mayo for one of two things: flavour (eg I love kerry gold on toast ;-) often nothing else) or moisture - but if I don't need the moisture, usually because I've got tomato, peppers, coleslaw, relish or something else providing that, I will leave butter and mayo out. Unless I want them for the flavour. (As an side, I don't understand why people would ever want butter on a breakfast roll)
"... usually because I've got tomato, peppers, coleslaw, relish or something else providing that..."
These are precisely the instances in which I would want something oily (butter, marg or mayo) as waterproofing for the bread. (Mustard also works, if it's appropriate for the sandwich.) "Everyone has the gout," as they (don't actually) say in French.
I feel I should give credit where it's due - while I'm no fan of butter on sandwiches, the butter here is fantastic, and makes for delicious toast, popcorn, etc.
I just don't need a peanut butter and butter and jelly sandwich.
How could you eat it without butter? Isn't it far to dry to be eatable? But this could be because of the difference in bread, just image-google "bread" vs. "Brot".
I grew up in the mid-Atlantic region of the U.S. and saw it both ways. Butter on sandwiches just sort of seems like just another way to make one, like some people like Mayonnaise (I don't) or not. I'd probably put it on a jam sandwich, or a ham and cheese, but not a PB&J (the Peanut Butter takes on the same role).
Of course I also grew up in very immigrant heavy areas so that may have been part of it.
Just to be clear: are you thinking of buttering the inside or the outside of a sandwich?
In the UK, standard practice is to butter sandwiches on the inside, ie on the surfaces of the bread which interfaces with the filling. Are you by any chance talking about buttering the outside?
I recently encountered this cultural difference (I grew up in Australia) with my wife (we live and she grew up in the US). My daughters vastly prefer my sandwiches to hers because I butter the bread (on the inside, the way God intended), usually using as little butter, or margarine, as possible. When asked why, I say it's mainly because it prevents the moist stuff in the sandwich from turning the bread to mush, but also because it tastes good.
I think a lot of it comes down to the fact that most sandwiches these days are prepared and then eaten right away, whereas I was brought up in a world where sandwiches tended to be prepared long in advance of being consumed.
That said, Americans will cheerfully slather "mayonnaise" on bread.
In Germany it's common but regionally different. My Swabian friends thought it weird I'd do that but my family is from the North. After 25 years in the US I now think it's gross.
This approach makes sense for a procedure you know exactly how to do. In the case of a procedure I do not know, I break them down into simpler and simpler pieces. Until I get to one I can do, then come back up the graph. Maybe akin to a depth first graph
example story: as a user I would like a form page that take an address I enter and renders a google map of it
No, you don't have to know exactly what to do. The key idea is that you can always correct it later as your understanding about the problem grows, but you can always start by writing the code the way you think its going to work (sort of like a plan)
High level overview:
var form = renderForm();
form.onAddressEntered(function (address) {
renderMap(address)
});
How do I show a form? Ah, I do that part in HTML, so no need to renderForm()
How do I access the form? Hm, its not an object. Maybe I should make it one, maybe not. I'll simplify this time, as I don't know what the future will bring:
Okay, so how do I run something when an address is entered? (reading, experimental code in REPL). Right, so the best way is apparently by attaching to the submit handler of a form. Oh, and I also learned that the handler takes an event argument and I need to call e.preventDefault()
onFormSubmit('address', function (address) {
renderMap(address)
});
Wait, how do I get the address?
Lets see if there is a pre-made function to serialize a form. (looks up) Ah, found it.
Lets modify onFormSubmit again. It should now add an event listener to the selected form which serializes the form and prevents the default submit event.
function onFormSubmit(form, listener) {
var form = document.getElementById(form);
form.addEventListener(function(e) {
var data = serializeForm(form);
e.preventDefault(); // which is submit
listener(data);
})
}
Back to the original code
onFormSubmit('addressForm', function (data) {
// lets make sure we got that first part right
console.log(data.address);
renderMap(data.address)
});
In the process, a neat utility for forms came out - a function that attaches a submit listener that gets all the form data.
So how do I render a map? Etcetera.
I think its important to always have a written-in-code high level overview of the process, even if it turns out that the current high-level overview is potentially wrong. You can always change it as your understanding (of both the process and the tools) grows. But at the end, that overview becomes your code, and the end result will unavoidably end up as understandable as your current understanding of the entire thing.
The hardest part of this process is to stop worrying about getting all the details right (at the beginning) and only focus on whether the code you're writing is describing your understanding of the problem well.
For example, suppose I'm a new programmer given the notional task of making a program to make me a sandwich, can I just:
and be done with it?Or do I need to break it down to the n-th degree?
is that the right way to even make bread? Or do I already have bread I can work with someplace?Do I?
Or Or do I need to do something else? Maybe this particular programming environment doesn't need me to make bread, but I have to transform a milk object into butter for some reason that seems entirely random to the new programmer. Who knows? Lots of the things that we take for granted seem entirely arbitrary to the new programmer and learning to break a problem down in a way that maps to the environment is a very hard problem to learn to solve repeatedly.edit in a way this is a common topic even on HN with the "do x in n number of line" posts that are common.