Chapter 15 - Writing a larger program #
- Prototype before polishing. Get it working before optimizing it.
- Separate policy from mechanism, separate interfaces from engines.
- Write simple modular parts connected by clean interfaces.
- Design programs to be connected to other programs.
- Write programs to write programs when you can.
- Design for the future, because it will be here sooner than you think.
- In interface design, always do the least surprising thing.
- When a program has nothing surprising to say, it should say nothing.
- When a program must fail, it should fail noisily and as soon as possible.
- Write big programs only when it is clear by demonstration that nothing else will do.
- Consider how you would solve your immediate problem without adding anything new.
Programming can seem scary at first but the more you exercise, the easier and more exciting it gets. After all, practice makes perfect! :)
Object Oriented Programming #
Software Engineering #
Software Engineering is a fucking nightmare. You’ll hear terms like Agile, Scrum, Stand-up, Sprints, Kanban Boards, Test Driven Development, and the word “Actionable” enough that it makes you want to puke. The entire process is the corpratization of code, the distilation of a creative art into something gray and bland, lifeless and dull. They’ll tell you it makes your code better, more organized, better tested. That this is the true way to do software development and that it’s necessary for writing good code. That all the best startups use all of these things 110% percent of the time and look how great they are, all the employees have access to an arcade at work, unlimited beer and soda at work, a pool table at work, a gym at work. Hell, they even do work at work! But maybe, just maybe, there should be some things that… aren’t work? Is that a radical idea, that a work life balance means going home at the end of the work day and not working 60 hour weeks for a 40 hour salery so that you can meet a deadline of self-assigned deadlines. No, I will not talk about software engineering in earnest on OpGuides because the entire field is one of masochism and unsustaniability, where the only focus is to make a product good enough to sell to a larger, more abusive corprate overlord.
Im not saying all the buzzwords above are bad things, I don’t think they are. My problem is with the workaholic to burnout culture they tend to come along with as well as the inability to understand that humans do have emotions and are not, in fact, machines. Sometimes talking about something that is not actionable is still important just for the sake of thinking and letting the brain wander a bit. Sometimes it’s hard to write the test case before the code is written, as you may not understand the problem 100% yet. It’s the blind following of these ideas without thought about why they’re used that’s the problem. It often results in more code that is harder to maintain, instead of good, clean code. Being overly regid with any workflow- ironically even agile- without consideration for why it is used leads to a bad and unproductive work environment.
Having standards, workflows, tests, roadmaps, etc. are all good! You shouldn’t just merge in any shit code. The problems start when working with others it becomes expected to work and write code in one super specific way -not just like, use camelCase, but like, actual restrictions on logic or over adherence to SOLID to the point the code is made unnecessarily complicated and hard to follow, as more and more boilerplate code froms to tie all the mess together.
Development teams do need a good way to stay organized, I just think a lot of how it’s done in the Hail Corprate™ world results in worse code with more bugs and employees that need therapy.
Yes, you should test your code. Yes, some of these methods can help. No, you shouldn’t turn this shit into a bonafide religion and your workers into cultists. If in talking to others you can only think “What they’re saying isn’t actionable” you cease to be human.