Comment by mattbgates | Hacker News Reader

Comment by mattbgates | Hacker News Reader

Parent Full thread

With every project, I'm always learning something new. I went from building projects with dozens of files to less than 10 and try to keep it to just a single page. I went from spending months on projects to spending no more than a month on a single project, sometimes taking up to just two weeks to complete. I think it's the lessons of sticking to the logic and getting straight to the point with programming.

If there was anyone who helped me become a better programmer, it was my first tyrant boss, who was a complete asshole. I adopted his practices: write out what you want your program to do. What is its purpose? What does it do? How does it operate? Who will use it? Why? What will they pay for it? What will it look like? What pages will it have? Does it need these pages? And a bunch of other questions. It really helps to save a ton of time and keep you on focus.

He said to me: "You waste more time jumping into a program without direction than one where you spend a weekend just outlining what your program should actually do."

Really great advice that helped me write many programs.

Very right!

This is also the reason i always recommend to others to just focus on solving the main path in a program. Do what comes naturally and in as direct a manner as possible with no unnecessary distractions. This is the creative aspect of problem-solving. Don't bother about edge cases, exception handling, performance, design patterns etc. during this first implementation but just focus on meeting the specifications. This gives you a huge boost in Confidence and builds up Motivation for the next steps to make it industrial strength (only if needed).

The second step involves going over the first implementation with edge cases and exception handling in mind to make the Program Correct w.r.t. Specifications. The problem is now solved.

The third step is when you go over the second implementation and look to restructure/refactor the code with an eye to Modularity, Design Patterns, Best Practices etc.

The beauty with the above process is that, with time and experience the techniques in the second and third stages become assimilated and innate and now find expression during the first step itself! This is RPDM (https://en.wikipedia.org/wiki/Recognition_primed_decision) and you have now become a certified Expert :-)

Strongly agree. I often reach for pen/paper first and doodle a problem, just think about it deeply, poke at the shortcomings, think of scenarios where it might be inflexible, decide where not to over-engineer, etc before starting to write anything.

That’s pretty good advice honestly. Most people make the mistake of jumping straight to code without having the full picture in their heads.

I really like your thought about cutting down the files. I find it’s a really good practice to write and make cheat sheets. This gets me into the habit of removing all the extras and try to get the core idea in a single file.

You might find this interview with Arthur Whitney relevant - https://queue.acm.org/detail.cfm?id=1531242

He is an extreme proponent of writing very terse, compressed code in as few files as possible so as to enable him to read/mentally execute more of his program in a single screen/page and without too many context switches.

See also : https://news.ycombinator.com/item?id=32202742

Reply on news.ycombinator.com