Consensus

Recently, I’ve been lucky enough to find more personal blogs with a similar theme to this blog: A programmer trying new things and jotting down what they think about the technology without the technical details. What I’ve found so far has been a pretty consistent body of knowledge. Everyone appears to agree on the same basic tenets but takes their own personal spin based on their needs and origins. These aren’t persuasion pieces, there’s generally no central argument or consistent theme. The authors dutifully and sometimes colorfully expose their thoughts about experiences with technology. Most are unsurprising because they use the same supporting arguments, so every conclusion follows logically. It’s also great fun to pick out a story that clearly missed one or two of the basics and falls to pieces in the comments.

The blog topics sometimes use an example to illustrate the tenets of the philosophy of software engineering that aren’t taught in classrooms or learned from daily experiences. It’s not the discussion that X technology is good/bad because Y, it’s the dissection of arguments to evaluate tools and organizational methodologies. These meta-discussions aren’t quite practical knowledge; they won’t improve application of algorithms, tool usage, or design patterns, but they will help describe how and why programming ecosystems evolve. It’s not PLT, unless it describes how PLT relates to how people and organizations make choices. This type of writing is the design critique of the software engineering world, it’s supremely subjective but somehow consistent.

This is my attempt at boiling down these common themes to something more abstract than Pragmatic Programmer rules:

1. Communication is the toughest part of programming. Reading & understanding the purpose of code will eventually be tough in any environment of sufficient complexity, so make every effort to make it easier. Get a consistent environment, powerful tools, and familiar syntax.
2. Pick what you know if you want to be productive, pick something new to have fun. Rewrites can be fun, and most of the time the technology choice actually doesn’t matter(within reason) if everyone who’s working on it can agree.
3. Understand what level of abstraction you work at. Learning outside that level is tough and honestly most people can get by fine without it, but everyone gets really confused whey they take assumptions from one level to another where they may not hold true.

I’ve come to the point where I feel like I’m reading the same points over and over. It’s really difficult to get a diverse set of views since it looks like everyone who blogs reads the same books and blogs so eventually it all just mixes together to this assumed consensus. There are blogs that avoid addressing any philosophy aspect and instead just go deep on a single technology stack or principle. Lightly covering a wide range of technologies doesn’t seem to offer any deep insights, just recycled truisms.

With all this reading, I might be able to guess what the next ‘disruptive’ technology is, but right now I’m knowingly blind to some ideas that haven’t made headway in this blogging consensus of HN. I guess I’ve been caught up looking for something new, something revolutionary, but since everyone else is looking for new things as well we all end up looking at the same things!

Maybe I need to go back and read some Knuth or SICP. CLRS wasn’t high level enough to spark any creative ideas.

Either way, I’m going to try to lay off other people’s blogs and stick to recording my boots on the ground