The Way I Code (and have been coding for 30 years)
Start with good decomposition. Then use encapsulation to create good abstractions. That's how I code. That's how I was taught to code 30 years ago. And it's still how I code today.
Creativity, curiosity, and code
Start with good decomposition. Then use encapsulation to create good abstractions. That's how I code. That's how I was taught to code 30 years ago. And it's still how I code today.
I want to talk (again) about friction. Things that slow us down. How some friction is good, and some is bad.
You kinda have a relationship with code from your projects. You probably have feelings about it. As I've been thinking about code style, I've also been thinking about how it's important to build up trust in a code base.
It seems upside-down, but sometimes when you're at the bottom of the pile, you can see a whole load more looking back up! And there's opportunities for programmers here.
I'm currently running...err...at least 4 small web-based projects at the moment, so I'm getting to grips with Hosting, DNS and CSS again.
Nothing...NOTHING I've ever come across is as unpredictable, complicated, difficult to get right, and downright confusing as this.
Developing a computer program of any size, like any engineering trade, requires some tools and some planning.
I wonder if such a large collection of technologies has always been required to write a business application?
JavaScript's all making a lot more sense, but I still think it's a bit of a daft language.
I'm still playing with Web Development languages and tools...but I'm really not liking JavaScript.