Reddit mentions of Hackers & Painters: Big Ideas from the Computer Age

Advice is cheap, so take this with a grain of salt. But programming is one of the few jobs in which it's easy to make a lot of money being creative. Not to mention it's a lot of fun, and in high demand. I would highly suggest reading Hackers & Painters to get a feel for what makes it so fun (the author of which is a big reason Reddit exists).

The amount of planning you have to do scales with the complexity of the project.

Professors drill the importance of planning, documentation and unit testing into students because it is extremely important and once you start your career if you're a poor planner it's going to come back to haunt you.

However, when you're working on a simple project that's not intended for public release you don't have to go overboard with docs unless you just want to practice.

My own process usually starts with me jotting down an idea; I find that writing it out helps me to get a better grasp on the overall feasibility.

Once I'm satisfied that I actually have something I can implement I'll diagram the flow of the application, and maybe do some wire-frames.

I usually find that this is enough of a launching pad for a simple personal project.

Professional projects are a different ballgame, because as I said, the amount of planning you have to do scales with the complexity and size of the project. It's in the professional environment that all of the things your professors are teaching you will become really important.

So, to answer what I think was your question,

>So how does one end up with 20 classes connected with each other perfectly and a build file that set everything up working flawlessly with unit test methods that check every aspect of the application?


This comes about more in the implementation phase than the planning phase. I've heard it said that in war "no plan survives contact with the enemy" and you'll find this to be true in software development as well. Even when you plan really well you'll sometimes have to go back to the drawing board and come up with a new plan, but that's just part of the process.

Some books that I recommend on the topic are Hackers and Painters - Paul Grahm and I think every software dev should have a copy of Design Patterns

The former is a collection of essays that might give you some useful perspective on the process of writing software.

The latter is more of a reference book, but it's helpful to become familiar with the patterns covered in the book so that you don't find yourself re-inventing the wheel every time you begin a new project.


As for the other part of your question (apologies for addressing them out of order)

>My new "bottleneck" writing code is the structure. I end up having huge classes with way to many public methods. I might as well just write a script with everything in one file. Almost anyway.. I try to write OO, but I often get lazy and just end up with not very elegant systems I would say.

Don't be lazy, because as you're already seeing, it comes back to bite you in the ass.

As you're writing your code you have to be mindful of the complexity of the project as it grows around you, and you have to periodically take a step back and look at what you've created, and re-organize it. This kind of goes back to what I was saying earlier about no plan surviving enemy contact.

So when you find yourself creating a new class that you hadn't thought about, be mindful of where you put it.

Should you create a new file (yes, of course you should), new folder?

Do you have a bunch of similar classes doing the same thing? Should they inherit from one another?

Be especially mindful of copy and pasting from one are of your code to another, generally speaking if you're doing this you should probably be writing a function, or using inheritance.

It's up to you as the developer to make sure your project is organized, and now-a-days it's really easy to learn how to best organize code by looking through other peoples projects on github, so there's really no excuse for it.

Hope that helps, good luck.

I first came across him as a wide ranging essayist sometime shortly after the first dot com crash (where he made a bunch of money). I actually remember when Graham started writing essays about startups; I was pretty annoyed, because I really enjoyed a lot of his essays before that point, and the startup stuff struck me as much less interesting. To be honest, when I first came across Scott, my first reaction was that he kind of reminded me of Graham at his best, in his prior-to-startup essayist phase. Take that for what it's worth.

I'm thinking here of essays like Grahams "Why Are Nerds Unpopular", for example : http://www.paulgraham.com/nerds.html

I would say that the thing that stuck out to me about Graham during that phase was that he was clearly a very sharp programmer, but he also was very interested in society and culture and thought about them in a way that was interesting and often surprising, more like a really sharp pundit with a more humanist orientation than most smart programmers I know. Even when he was generalizing, which he often was, he'd be working around some big idea that would linger after the end of his essay.

A curated selection of his essays is here : https://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp/1449389554

No, you're confusing wealth and money. Wealth is anything of value, and because people are constantly working to make products and deliver services, wealth is ever-increasing. Money is somewhat of a net sum of zero, but this is not as much of a problem because people can increasingly accumulate wealth.

If you build yourself a house, you have created wealth. No one loses anything from your efforts. If you then choose to sell the house, money will be transferred, but this is incidental and not very important because the buyer of the house can create their own wealth, say, through making trinkets. Them trading their (large number of) trinkets for your house benefits both parties. Money is just a means to trade the wealth created by one person for the wealth created by another. In this example, assuming a fair trade of trinkets to house, both parties are better off, and no one loses wealth.

Because wealth and money are different, everyone can gain wealth without anyone having to lose wealth. Money will change hands, but this is necessary to conveniently trade wealth.

I highly recommend the book Hackers & Painters by Paul Graham. In chapter 7, he discusses this topic at length.

In Hackers & Painters, Paul Graham submits that hacking is more art than science. I think probably that's true of great hacking, but for many people I've worked with it's a means to an end like you say, not a form of creative expression.

I'm not a great hacker (I've also worked with great hackers so I know what their work looks like), but I still relate to Graham's essay quite a bit and try to make code that I and others think is beautiful.

> more that the problem you are solving should be clear, and you should have an understanding of how you are going to solve it. Then start writing code by all means, even if you havent planned any code structure specifically

Ok. But then I would argue that this is similar to the process that writers follow. Maybe Palahniuk didn't know everything that would happen in Fight Club, but he surely knew that (spoiler) Tyler Durder was an alternate personality of the protagonist (disclaimer: Haven't read the book).

> I will go off and read some Paul Graham

I recommend it. Check out his book Hackers And Painters.

A little off topic, but I can't recommend this book enough: http://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp/1449389554

Also, if you aren't already on Hacker News:
http://news.ycombinator.com

Good luck!!!

I'm not sure if this is what you are referring to, but I enjoyed reading Hackers and painters by Paul Graham.

Maybe you would also like cyberpunk? William Gibson is an obvious choice.

Startups are much more complex than real-estate deals, so you aren't going to find as concise of a book as the Art of the Deal, Zero to One as recommended in another comment is a great one though.

For the ethos of startups I would recommend: Hackers and Painters by Paul Graham
https://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp/1449389554

For the nitty gritty of deal making with VCs (I still haven't made it all the way through this one, as it gets very in depth for someone who isn't quite at the point of looking for funding) this seems to be the go-to:
https://www.amazon.com/Venture-Deals-Smarter-Lawyer-Capitalist/dp/1119259754

If you're doing a technology startup especially, a couple of books from the YC guys: Hackers and Painters and Founders At Work.

> .NET is open source.

Johnny-come-lately

> Besides, what exactly is saner about other options are you talking about?

Everything isn't driven by whatever Microsoft deems important for its own bottom line, for starters. Here's an example of the direction that took us, possibly before your time, but caused me a tremendous amount of webdev hell in the 2000's (like, the entire decade).

Here, read this, you'll understand much better. Between that book and this one, your life might change drastically. Mine did.

Hackers and Painters by Paul Graham? Di ko pa sya tapos basahin tbh pero gusto ko sya. Especially yung unang chapter about the us nerds. haha

Read Hackers & Painters (www. amazon.com / Hackers-Painters-Big-Ideas-Computer/dp/1449389554)

I loved: Hackers & Painters and I think it fits the "about software but not a dry tech spec manual" genre.



Side note: Enjoy CS50 and I highly recommend at least watching CS75