Here are a couple of reasons to reconsider your attitude: Stop being so agreeable! by Erick Erickson.

We understand our limitations. And we build around it. But for some reason when it comes to the mental world, when we design things like healthcare and retirement and stockmarkets, we somehow forget the idea that we are limited. I think that if we understood our cognitive limitations in the same way that we understand our physical limitations, even though they don’t stare us in the face in the same way, we could design a better world.

(my italics)

I think that is a very important point. Software development is a purely mental process. We take ideas, translate them into code. We’re authors, our audience is a CPU. We write in RAM chips instead of on paper. But basically, we’re translators.

Most software developers know their tools but not their own mental limits. Ask yourself: How much brain power does it take to type on a keyboard? Got your number?

It’s about 30%. When you type yourself, you only have 70% of your brain left to think what you’re typing.

Software development is a craft but it’s not like smithery. We had anvils and fire pits at my school. When you work with yellow-hot glowing steel, a five-pound hammer and an anvil, you learn something with your first strike: This is dangerous, this is hard work, this isn’t as simple as it looks, and how fast you’re going to tire.

How do you do that? Because your brain is wired by millions of years of evolution to know such things. Your muscles are designed to give you feedback: Can I outrun my enemy or do I have to make a stand? Forging steel is built into us. The result will vary with clumsiness but every person in my class was able to hit the steel with a hammer. It takes a day to teach someone to write the most simple program in Java but it takes one sentence to teach them how to flatten iron: “Take one of those hammers and hit it here.”

If driving steel is so simple, why are we so bad at software development?

Well, it’s one of those tasks where one brain tries to achieve two conflicting goals: Write software and at the same time watch itself doing it right. It’s a dilemma. You have 70% tops unless you have trouble at home, worry for your job, are hungry or mad at the guy next door yelling in his telephone. How much of the 70% are you going to give to “write software” and how much to “do it right”?

That said, being a software developer, you’re male (98% chance). Males suck at doing two things at a time and you’re already doing at least two. How much good is adding control to the pile going to do?

Probably not much. So what can you do?

First: Don’t forget that you’re limited. Clear your brain. Heed your limits.

Second: Turn your limits into a foundation. Instead of struggling with them, accept them. Use techniques like Test Driven Development to do one thing at a time: Tests answer the “do it right?” part. When you have the test, you can forget about this and go the “write software” part.

Use you limits. They are tools just like everything else.

Main points:

• “Congress does not go to NASA halfway through a moonshot and ask them to go to Mars instead.”
• When building a house, it’s pretty hard to make the toilet flush when you ring the doorbell. In languages like C++, it’s very hard to make 100% sure this can’t happen.
• Is it science? No, science is about conducting experiments and accumulating knowledge.

I don’t agree with software == art. Art is meant to make emotions available to a larger audience. Maybe writing error messages at M$ is an art form but general coding isn’t.

Conclusion: Software development is a craft just like carpentry or masonry.

Related articles:

• The placebo effect is what makes the software world go ’round

   

Funny, right? But it got me thinking.

How important is it really that someone knows this? With over 60K points on stackoverflow, I’m one of the most knowledgeable software developers in the world but there was a moment, when my brain stumbled over the question. I rarely use final in my code. So how much value does this information have? How often do I need this every day? Once per week? Month? Year? How much damage can the wrong answer cause?

While I agree that sound knowledge helps a lot, I see team mates struggle much less. They don’t know as much as I do but there is a demotivating effect here: If you know too much, every simple question triggers a flood of thoughts: What can go wrong? Didn’t we encounter this already? What’s the best solution?

Sometimes, there are two “best” solutions and missing any further input, I can get stuck in a deadlock. Which way to go?

Or the solution to a problem triggers a new problem which in turn triggers a third. Suddenly, I’m caught in a maelstrom of dread which overwhelms me: Every possible way out just causes more trouble.

So for me, knowledge isn’t everything. Some people are “just” decent developers but that should not stop you to hire them. Here are some other, valuable factors:

• How easily do they give up?
• How well do they play as a team? That doesn’t mean everyone has to be a “team player” (whatever that might be). But strengths and weaknesses of each individual should compensate each other. One guys likes to talk a lot, let him handle customers. The other guy likes to work alone, give him the hard tasks that need a lot of time and concentration.

Venkatt Guhesan has compiled a list of 11 tools that you should know about.

Now Ceylon enters the stage (slides from the presentation). The main goal is to clean up the SDK while keeping an eye on what was good and what was bad with Java.

I’ve had my share with programming languages. On a scale between 1 and 10 (best), Python gets 9 from me. Java gets 6. Scala gets 5.

So how does Ceylon fare? At first glance, I’d give it a 7.

Pros:

• Compact syntax. No packages, no classes.
• I like to idea of the recursive block scope which gets rid of the very limited public/private and the ill fated package public. My only concern is how you can declare friends to something at a nested scope (for example for tests).
• Short syntax to avoid NPEs. The approach allows to catch null pointers when they are assigned instead of when they are used. This means: If you find a bug, you’ll actually know what to do about it.
• No new keyword! I really never understood why they added that.
• No checked exceptions. No one got them right, anyway.
• Just one constructor per class. I never use them anyway, and the new named argument syntax solves many of the existing problems.
• Method references

Cons:

• = vs. :=. Come on. In 2011, I still need to tell the compiler something it already knows? Also, looking at my code, I’ll probably use := a lot. So that means extra effort for me. Bad. Not everyone’s brain is wired for immutables.
• “if (exists foo)” to check for null values. If I already have to use a special syntax to mark something as “can be null”, why do I need to mention that again in a condition? What’s wrong with “if(name)”?

Things that leave me puzzled:

• local vs shared. I understand that the compiler can’t infer types for shared references in a single pass but who cares? The compiler is a tool that has to make me more productive. If the compiler needs two or three passes to resolve dangling type reference, so what?
• How is the module system working? How do you bundle types in a container to keep the namespace clean?

Details can be found in this blog post.

if (statusIsNotValid.compareTo( Boolean.FALSE ) != 0) skipValidation = false;

Another great example why you should prefer positive logic.

Except that the mighty singleton has the same problems as the global variable – because they are the same thing.

A solution was sought and DI was invented. When people start to use DI, they are still in the “Singleton” mind because you can’t get rid of an idea that has served you (more or less) well over many years. Since a human can’t simply forget what he’s been doing for a long time (it’s traditional), singletons leaked into DI leading to odd design which felt wrong.

Software developers are paid for their brains. If something feels wrong, it usually is. Most of the early code we come up with then starting with DI violates the Law of Demeter.

A common solution to the problems with many singletons is to replace them with a single singleton (for example one which loads and offers the application context in Spring). While this is convenient, we still have a global variable left.

Another solution is to write constructors that take 27 parameters so you can pass in all the parameters. If you avoid that trap, then your class will have 27 setters. Holy Ugly, Batman.

How to solve that? Use more DI. Most of the 27 ex-singletons will be passed on to other worker classes. So instead of passing on the singletons to create the worker classes deep down in the code, create the worker classes using DI (so the DI framework can fill in all the ex-singletons they need) and then pass in the 2-3 workers.

For some code, see this article: Dependency Injection Myth: Reference Passing