3 ms·

I'm a talented programmer but wasn't always so. The most important thing I ever learned was how to plan a program into abstract components that are as isolated

by edoo 8y ago

I'm a talented programmer but wasn't always so. The most important thing I ever learned was how to plan a program into abstract components that are as isolated as possible BEFORE ever touching any code. If you plan an abstract hierarchy correctly you don't have to try and keep the entire swarm in your head. You can focus on the individual components and when they are done, forget about the implementation and refocus on the next level in the hierarchy. If you run into issues step back out into the planning phase. Never write code without a plan. When I was younger I could barely get 1k lines of code down without it being a mess. Now I can build complex applications with multiple libraries in the 20k-40k SLOC range without much mental effort. It is almost like entering and leaving functions in your brain.

Sileni 8y ago
I think that's what he was referring to by "bottom-up programming". Essentially, make your abstractions air-tight and grok-able and you never have to worry about what the abstraction contains again.
jpmoyn 8y ago
Do you write the plan down? Like an outline? I want to get better at what you are describing.
- edoo 8y ago
  Better put you build the components with the least dependencies first after your software architecture is decided, up to and including pseudo code, to the point you are confident in the design and are not required to think about it while implementing it in real code. If a design issue comes up stop programming and fix the architecture. I'm a graph paper guy myself. Say a racetrack library. We have a 'racetrack', it has a 'list' of 'cars', they have a 'list' of 'tires', and 'list' is a custom class and we know how it is all going to fit. Now normally you might start with a 'racetrack' class, start a car class, start the list class so you can have the cars on the racetrack, start the tires class. Add functionality to the list class to get something to work. You leave a trail behind you that if you try to keep in your head can get pretty awful in big projects. If you start with the objects with least dependencies you can forget about them once you are done. 'list' has no dependencies, you can make the class (and all test code if desired) and forget about it. Now you can focus entirely on a tire (and all test code if desired), and forget about it. Then you do the car class fully, then the racetrack. At every level you have everything below it done so you can fully complete the implementation in one shot instead of bouncing all over the place . It isn't always perfect but it really cuts down on the brainpower you have to expend. This is best suited with unit testing. At first it can feel ungratifying to program this way, even scary. You could be 85% done with your planned architecture and have almost no visible behavior of your final product, with that last 15% being the actual high level abstractions that really tie everything together and the project just seems to pop into completion.

by edoo 8y ago

Sileni 8y ago

I think that's what he was referring to by "bottom-up programming". Essentially, make your abstractions air-tight and grok-able and you never have to worry about what the abstraction contains again.

jpmoyn 8y ago

Do you write the plan down? Like an outline? I want to get better at what you are describing.

edoo 8y ago
Better put you build the components with the least dependencies first after your software architecture is decided, up to and including pseudo code, to the point you are confident in the design and are not required to think about it while implementing it in real code. If a design issue comes up stop programming and fix the architecture. I'm a graph paper guy myself. Say a racetrack library. We have a 'racetrack', it has a 'list' of 'cars', they have a 'list' of 'tires', and 'list' is a custom class and we know how it is all going to fit. Now normally you might start with a 'racetrack' class, start a car class, start the list class so you can have the cars on the racetrack, start the tires class. Add functionality to the list class to get something to work. You leave a trail behind you that if you try to keep in your head can get pretty awful in big projects. If you start with the objects with least dependencies you can forget about them once you are done. 'list' has no dependencies, you can make the class (and all test code if desired) and forget about it. Now you can focus entirely on a tire (and all test code if desired), and forget about it. Then you do the car class fully, then the racetrack. At every level you have everything below it done so you can fully complete the implementation in one shot instead of bouncing all over the place . It isn't always perfect but it really cuts down on the brainpower you have to expend. This is best suited with unit testing. At first it can feel ungratifying to program this way, even scary. You could be 85% done with your planned architecture and have almost no visible behavior of your final product, with that last 15% being the actual high level abstractions that really tie everything together and the project just seems to pop into completion.