
Two Approaches to Learning Programming: Top-Down and Bottom-Up - boyakasha
http://www.programmingforbeginnersbook.com/blog/top-down-bottom-up-approaches-to-learning-programming/
======
tannerc
Most of the engineers I know learned to program via "top-down", as did I
(though I'm a designer).

Whenever anyone asks me how to get started in programming, I tell them to
forget about buying any of those "Dummies Guide" books and instead just pick a
problem they're really passionate about and Google anything they need to learn
to make the idea happen.

Such an approach certainly doesn't teach you a lot of the most important thing
about programming (garbage collection, what types of objects to use and when
to use them, etc.) but it does get the job done.

And that's the thing I think matters most for those just starting out: if you
try to learn bottom-up and get all the fundamentals, you're going to burn out.

Of course such advice goes right out the window if your goal is to actually
become a real, breathing, programmer. Because you can't afford to make
mistakes and the foundational stuff ensures you're less likely to do so.

Whereas just Googling how to put together a project will likely leave you with
a functional project, yes, but also less-than-ideal code.

~~~
lilactown
This is why I say that JavaScript is a great first language. Not because it
teaches you how to write good code, or be a good developer, but because the
barrier to entry is so low to get started; with a text editor and a web
browser that everyone has on their system, you can start making something that
has a tangible (visible) result. That's powerful.

Once a person has a handle on things like how code is structured and
interpreted, syntax, objects, etc. then you can introduce them to the terminal
and start teaching them Python if you want. But nothing comes close to driving
interest like making a button on a screen that moves stuff around.

~~~
rjbwork
Ditto. I suggest JS => python => *

And I very much dislike JS for actual professional use.

------
corysama
I find it mostly depends on your personal motivation. If you somehow are
magically motivated to slog through a huge amount of crap that seems
meaningless and pointless to everyone else, bottom up is preferable. You'll
end up in a better place in the end. But... it only works because you see the
meaning and point of investing a large effort before the tangible payoff.
Bonus points if you find the slog to be fun in and of itself.

Naturally, a lot of professors and highly talented experts tout this as the
only way to go. It worked great for them and they don't see the point of any
other path.

But, in my observation, "talent" is usually a false explanation of someone who
is highly motivated by something I'm not aware of. Most "talented" people I've
known were actually putting in a huge amount of work in the area.

On the other end... if the return on investment isn't clear. If the path to
the payoff is branchy, windy and foggy. If you are motivated by results, not
process. Top down is a good way to determine if it really is worth the effort.
In the meantime, investing some extra effort in finding the payoff and the joy
in the process would be wise when taking this approach.

~~~
AnimalMuppet
Bottom up may require a different learning ability. You read something, and
you don't have a mental hook to hang it on yet, because you don't have any
idea of the overall framework. So you have to be able to leave it hanging in
midair for a while, until you learn enough of the higher-level structure to
understand how it fits.

I used to be better at that when I was younger...

~~~
aassddffasdf
I think you have that backwards. Bottom up is about the composition of already
understood pieces into more powerful ones (the utility of which is obvious due
to solving limitations/ inconveniences inherent in the previous layer).

------
AdeptusAquinas
_Then the teacher tells you that most professionals don’t code this way
anymore. So you start learning about classes, and instances, and instance
variables, and methods, and inheritance, and a whole bunch of other object-
oriented programming concepts. Then you try to unlearn the way you originally
learned to write code, and learn to write code in the new object-oriented
way._

Missing next line: "Then you get a job and your colleague tells you that most
professionals don’t code this way anymore.

~~~
SadWebDeveloper
Missing next phrase: ", we are still using Java".

------
RubenSandwich
What about the approach of Middle Out: where you neither build anything beyond
copy and pasting code nor learn why doing comparisons on floats is a deal with
the devil?

Joking aside, it does seem that a mix of the two is nice. Bottom Up is boring
when you just want to get things done and Top Down is magic until you try to
leave the playground. The problem arises that each student will have different
tolerances of each of those approaches.

Edit: Maybe an interactive book, or app, that lets you see a problem from both
angles and let's you pick the problem you want to solve. Here is a problem:
"Given this graph data summarize and display it". Bottom Up you learn DFS and
Top Down you learn d3. With if you pick one or the other your given a library
to fill in the part you don't like. You could always return and do the other
part latter as well.

~~~
patleeman
Middle out is how I learned to program actually.

I started with basic lessons on Codecademy to learn the basic concepts and
jumped between reading books and researching concepts and building small
projects. I feel like I got the best of both worlds. When I hit a concept I
didn't understand or needed clarity on, I went and researched the underlying
fundamentals.

I've seen developers that have gone top down and they struggle with basic
programming logic because they don't have the fundamental knowledge. On the
flip side, I can't imagine studying CS and learning all the CS fundamentals
without going ahead and building stuff the whole time.

------
dangom
An then there is the SICP approach, a Bottom-up feels like Top-Down that
proves that the two approaches need not be mutually exclusive.

~~~
kmicklas
Yeah it's a false dichotomy.

------
Const-me
There’re no fundamental concepts.

If you’ll start with C, there’s assembler and machine code underneath.

Underneath there’s memory hierarchy, CPU microarchitecture, buses, and other
things like USB protocol stack.

Underneath there’re logic gates, comparators, summators.

Underneath there’s physics, quantum mechanics, electrodynamics.

Each of these abstraction levels is fundamental relative to the upper one.

The level of abstraction that you declare fundamental is arbitrary. You can
define your “fundamental level” threshold much higher, e.g. JVM or
S-Expressions, and start bottom up from that arbitrary level.

The level a median developer believes is fundamental drifts upwards over time.

70 years ago it was impossible to be a programmer without knowing about logic
gates. The majority of modern software developers can’t design stuff from
logic gates, they don’t even know much higher-level USB protocol stack, and
yet they are able to do their jobs just fine.

------
danbruc
I have thought quite a bit about how useful a course with theoretical and
practical elements from silicon atom to HTTP request would be. You start
building an AND gate from MOSFETs, an adder from 4000 series ICs, a simple
processor on a FPGA, you write Tetris for your simple processor, and then you
switch over to a real computer, operating system fundamentals, data
structures, algorithms, protocols, ...

That is certainly a lot of information to process, but if designed well it
could be like one big project where you regularly end up with a result and
then continue building the next layer on top of what you already have. There
would be a clear path to follow in order to not get lost in any layer but if
you wanted to, you could also keep exploring a layer for a while before moving
on.

Not sure if that would actually be a good idea or not, but at least
retrospectively that looks like an awesome way to really learn how to code.

~~~
khedoros1
This doesn't go quite that far, but takes a generally-similar approach:
[http://www.nand2tetris.org/](http://www.nand2tetris.org/)

------
flavio81
Better would be the DSL approach: Express the problem in an easy to
understand, natural-looking DSL and then implement the DSL. This is both top-
down (describe problem) and bottom-up (implenent DSL words) at the same time.

In common OOP languages (i.e. Java), the mechanisms of OOP can be used as an
ersatz DSL, albeit a bit limited.

------
kutkloon7
Nowadays, programming is much more complex than it used to be (unless you
consider toy programming languages). For me, visual feedback was always a key
factor in the things that I made. When I started, there was no top down or
bottom up. You just started programming, and you actually understood what was
happening because it was not that complicated.

Let me give you an example. QBasic is the first language that I learned.
Suppose you want to draw a white pixel in the left upper corner on the screen.
To do this, you can do: SCREEN 13 PSET (0, 0), 15

If you understand this and for-loops it is trivial to fill the screen with a
color. Then the next step is to make the color of the pixel dependent on the
position. I made some wonderful graphical stuff with this (rotozoomers,
plasma, fire effects...).

Now, if I want to do this in C(++), I probably can, but it will take me at
least an hour of research. Same thing for C#, Java, Haskell, and so on.

This is not a completely fair comparison since QBasic ran in DOS and there was
no need to summon a window, but that is exactly my point: things keep getting
more complex. To plot a colored pixel on the screen in QBasic, you have to
know about pixels, screens and colors. To do this in a more modern
environment, chances are you have to pick the right API and understand all
abstractions it introduces (probably including windows, graphical contexts,
buffers...). The trend seems to be to ever more abstract, complex, and
powerful frameworks.

If you are already a programmer, this is a gradual progress and it is feasible
to keep track of everything, but for new programmers it takes a looooong time
to get up to date with all the new abstractions that people have come up with
(and I think are not always that important to start programming).

Now I'm not saying that we should not introduce abstractions or frameworks or
implying that DOS graphics were better than today's system with windows. I'm
just saying that these advances come at a high cost, and I don't know if there
is a solution.

~~~
Const-me
Why don’t new programmers start with stuff like this?
[https://processing.org/overview/](https://processing.org/overview/)

------
steve_bruce
I tried the top-down method but I figured out that I was a type of person who
should learn the basics first and then develop knowledge from that.

I think that the Bottom-up method is better overall.

------
hdhzy
That's an excellent advice and it works because people are motivated and have
a tight feedback loop ("is this what I wanted?"). Arguably this is the best
way to learn if you follow it with some deeper reading on the subject once you
have a working solution to close gaps in your understanding.

------
apeacox
I usually start with Top Down to get a big picture quickly, then I do Bottom
Up to dive deeper in details.

