Comment by jakevoytko | Hacker News Reader

Comment by jakevoytko | Hacker News Reader

Noticing pain points. It takes time to develop a taste for good solutions. But when you modify or write code, and you say, "this is harder than it should be," this is a code smell and there is a better way to globally solve the problem.

Thinking first, writing later. When practicing for the ACM programming competitions in college, I discovered that when writing code before understanding the solution, I eventually needed to start over. I have never seen a counterexample.

Learning new things. Every year I try to learn a new major skill. Two years ago I learned Common Lisp, last year I hacked on some AI textbooks, and this year I'm teaching myself how to build websites in Python. Try for some variety - Alan Kay said "Perspective is worth 20 IQ points," and while I make no standardized testing claims, learning from multiple fields can connect the dots in interesting ways.

Reading code. Norvig's PAIP knocked me out of my Object-Oriented rut and changed how I think about coding problems.

Working with smart people. Surrounding yourself with motivated and effective workers has a great multiplying effect on your own productivity.

"Thinking first, writing later. When practicing for the ACM programming competitions in college, I discovered that when writing code before understanding the solution, I eventually needed to start over. I have never seen a counterexample."

The thing is. Some times writing code is how you best come to understand the solution. One of the things that have made me a better programmer, was exactly realising this. If there is something I don't understand, I now try to program it, rather than thinking too much over it first. Call it prototyping if you want. It's a fine line of course.

I like what Fred Brooks says here, something along the lines of: Be prepared the throw the first one away since you will anyhow.

I definitely won't disagree with anything you said in the general case, but for this:

Thinking first, writing later .... I discovered that when writing code before understanding the solution, I eventually needed to start over.

I think this may depend on how and when you think most effectively. Having the discipline to be productive in pure thought is impossibly difficult to quantify. At times I feel productive working that way, but other times just writing code helps me think through things faster. I type fast so it's not a big burden to type a lot of stuff even if I have to delete it.

Of course, sometimes just drawing things out on paper helps as well. I seem to recall Dijkstra making some criticisms of that, but for me it is often highly effective.

I think it's more "think about what you wish to accomplish with the piece of code that you're about to write". Are you trying to write something that will satisfy users' desires? Then you darn well better think about every aspect of those desires, and make sure that the code you write satisfies them. Or are you trying to learn what users' desires are, or how the technology you have available will help you satisfy them? In that case, you may be better off just diving in and coding, but you should think about the question you want answered before you code.

I think you're both right. Some people do like the grandparent suggests and map their strategies out in advance. I personally do better with Brooks's "build one to throw away" approach. I like this better because I can't work with a plan like others do. I need to have implemented something before I can understand it. Others work better with a different approach. To each their own.

They're not mutually exclusive approaches anyway. Alternating between them quickly can be a good way to nibble away at hard problems. And it's not a big deal if you throw away some work in either mode. Think on what takes you there faster, not necessarily with less (wasted) work.

There's no clean path with regard to this.

Either you plan too much ahead and you end up tweaking your design forever, eventually building high-level cruft code that still won't get anything done because you don't dig deep to the ground to find the real culprits of your solution.

Alternatively, you plan nothing at all and end up rewriting your program several times because you just won't see the big picture as you're just digging up dirt from many different spots.

I think it works best if you plan only as much as you initially can and then start coding a proof-of-concept version as quickly as possible. You can only plan what you know of, and it's not much at first but it's something. Quickly getting to coding helps you understand the problem better, and you will throw away a many approaches that turn out to be suboptimal or solutions to the wrong problem, but there's nothing wrong with that. When the coding brings in more knowledge, then you can plan a bit more, and repeat.

If you're good, you can do that most of the most of the time. A conservative estimate might be half the time. More importantly, you will never hit the optimal planning versus coding point but you wave around on the both sides, sometimes planning too much and sometimes coding too much.

Experienced programmers can keep the amplitude of that zigzagging low, inexperienced programmers rush from endpoint to endpoint doing too much either.

Since I'm still in the early stages of learning to program (past the "durr what are for loops" stage, but still not good at a language), I've found that it's nearly impossible to really plan anything out.

I can plan out what I'll put stuff in and the names of the classes and methods that'll work with data, but I'm clueless until I start trying to implement the idea.

I suspect that once I've done enough things, it'll be easier to plan. I know when I go back to any of my old C# projects, I keep slapping my forehead and am able to see other (often better) solutions.

So I think the better advice is: Try until you know what you're doing, then toss it out and plan around all the terrible mistakes you made.

Quoting myself: You can only plan what you know of, and it's not much at first but it's something. :-)

Try this.

Design your program from high-level and iterate through phases into low-level. So for instance, I want you to make a program that, lets say, is a customer database.

High level 0: I need a customer database

Level 1a: I have these storage requirements.

Level 1b: I need these inputs

Level 1c: I need data to exit the system in these ways.

Level 2: Diagram of work-flow processes (how it interacts with real people).

Level 3: Diagrams of how the database will look, identify what types of objects you will need to work with (of course, this specific action gears you into OOP design and not functional).

Level 4: Problems. Spend some time bad-mouthing everything and how it works, go back to level 2 and when you're tired of crying about the thing go onto the next level.

Level 5: Document how it works. This is your Manual.

Low Level 6: Write the code, and when you need guidance, RTFM.

Level 7: Throw the thing into the trash and start over, they wanted an inventory management system, another tribute to the synergistic perspicacity of business people and software engineering's verbal constipation.

Reply on news.ycombinator.com