Here's how to build websites like Albert Einstein would.
There's two simple premises here.
- Albert Einstein was not only a great physicist, but was also good at solving problems
- Building websites also involves solving problems. Such as translating the build requirements into working code.
Building a website needs answers to real world problems like:
- How can we allow our clients non-technical staff to edit the content on their new web site?
- Or, how can we notify the interested parties that there's a new web order?
Those are the problems I'm talking about. Real stuff that web developers face on a daily basis.
I'm not going to define any particular framework or language. The only stipulation is: we are talking about developing for the web.
So, let's do some coding with Einstein.
Everything should be made as simple as possible, but not simpler.
The best way to think about this one is the hammer story. Think of a hammer. A handle and a steel head for hammering and a claw for extracting nails.
Let's make it simpler then, by removing the head. Now we have a handle, but no means to hammer with.
Ah, not simpler then. The hammer is well designed for the task in hand. Trying to simplify it further means it won't be a hammer any more.
That's a bit like writing a method in a class isn't it? Or defining what a model class is going to do. Each method should do one thing and do it well. Conditionals in a method could suggest you've veered away from simple as possible.
Right, here's another one:
We cannot solve our problems with the same thinking we used when we created them.
Web developers would accept that throwing more code at a problem doesn't always solve it. There are times when it makes sense to check your thinking about how solve the problem.
Do you need more code? Or do you need the same code written differently?
With the feature you are working on, could it be that you are thinking about it wrong?
The point is: when you hit a coding hole, changing your thinking might show you the best way forward.
The next one looks like this:
If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.
This one relates to high level design considerations. It's about understanding what's needed first.
Thinking things through first, will help prevent project creep .
Driving hard to find the right question(s) to ask means you'll get a far more targeted and useful brief. And that means you'll get closer to a proper solution the first time, rather than the nth time.
So, now we have a plan for building websites the Einstein way:
- Simplify as much as possible, but don't over simplify
- Change the context and change the thinking to get past tricky problems
- Make sure the brief is fully understood before writing any code
That sounds too simple, doesn't it? Think about your last build. Was it all plain sailing? Or could these principles have been useful?