Overcoming Code Paralysis…

Don’t take it sitting down…

Have you ever sat at the keyboard (or stood if you have one of those new fangled standy-up workstations) and not known where to begin on a new piece of code?

You know what you need to achieve, you know what the code has to do, you know how to code it, but the problem is where do you start?

What classes do you need? What should they be named? What folder should you put them in? What dependencies do they have? Etc… etc…

In the old days (before things like SOLID and TDD) it was straight forward. You would just place your cursor inside Main() and start coding. If Main() grew to more than a few hundred lines long you’d split some of the code out into functions, and resume typing.

Ok, that is a gross over-simplification and generally a lot more craftsmanship went into the proceedings than that. But the idea is the same, we didn’t fear knowing where to start, because it was OK to just start anywhere and crack on with it.

Through complexity comes slightly less complexity…

Now, with SOLID principles, every decision you make is governed by the fear of violating one of them. Am I breaking the Single Responsibility Principle? I really mustn’t new up a class within another class, I need to inject it as a dependency… Are my interfaces getting to big? Are my methods so well named that another coder could understand the intent of my code without requiring comments? Under TDD I need to start off with a failing test and I don’t even know what to name my first class, or what it should be responsible for…

The point is, paradigms like TDD and SOLID are awesome. They are the way to go (most of the time and depending on what you write). But they introduce an additional level of complexity (call it intellectual manageability if you like) that can very quickly induce code paralysis. You end up with so many rules governing how you should create your code that it can become difficult knowing where to start. And starting in Main() is generally not that place.

Q: So what can you do if you hit code paralysis?

A: Put your cursor on the screen and start typing.

It’s really that simple. Don’t just sit (stand) there, code something.

OK, I don’t know what my first class is even going to be called, how am I supposed to write a failing test for a class whose name I don’t yet know?

Don’t worry about it, you can get some code on the go and worry about all that later. Have a look at the following:

Assuming you’re using C# and MSTestV2, but the principles apply to any language and test suite…

Create a new file (anywhere in your project) and call it FooTests.cs

Create the FooTests test class in FooTests.cs.

Create your first test:

There you go, you have your first unit test written, and it will fail. The class Foo() does not exist so the test won’t compile, which is the same as a failing test.

So next you create the class Foo (do this in FooTests.cs – don’t worry about what the class will ultimately be named, or what file it should be in just yet). Remember, we’re just sketching at this point.

PS. In Visual Studio you just need to put the cursor on Foo and press Ctrl+. and select Create Type Foo to have the new class automatically created for you.

Your first unit test should now pass.

Time for the second test.

But what to test for, this is going to be a complex system with many moving parts…

Again, don’t get yourself bogged down with the details just yet. We need to chuck some clay on the wheel before we can make a beautiful vase.

We know our class needs to do something.

Write another test:

There you go, another failing test.

The test fails because the method DoSomething() doesn’t exist yet.

Put the cursor in DoSomething() and press Ctrl+. then select Create method ‘Foo.DoSomething’. This will add the missing method to your Foo class.

Your second test won’t pass because the auto-code completion adds code to throw a NotImplementedException. Whether this exception gets added to your code depends on your IDE settings. For now comment out the throw new NotImplementedException(); exception if one has been created and you’ve got another passing test.

Ok, we’ve got two passing tests. They don’t achieve a great deal in terms of functionality, but what they have achieved is to get us typing code.

You now have some clay on the wheel, a basic sketch on which you can build, and from here you can carry on with the red-green-re-factor approach of TDD as you continue to flesh out some structure and then move on to adding details.

As for the names Foo() and SoSomething(). Refactoring tools in modern IDEs are so good these days that you can easily rename these as you develop and re-factor the code.

When words fail you…

There are plenty of times when I find myself being bogged down with trying to think up a good name for a class or variable. When this happens it will either be because I am tired, or my code is heading in the wrong direction and the naming difficulty is a code smell that I might need to re-think part of the design.

In either case, don’t worry about it.

I just name the class BarrysFishAndChipShop, carry on developing the code, and before too long a better name for the class will present itself. In the case of BarrysFishAndChipShop a better class name will spring to mind quite quickly. But the point is it doesn’t matter what you call a class during the rapid development phase.

Remember that red-green-refactor cycles will usually be under a minute and often only a few seconds. I’m not talking about checking funny class names into source control for others to work on, remember that you are just sketching ideas at this phase and often after a bit of re-factoring the names of things will become very obvious.

The whole point is to snap your self out of code paralysis, and do something. Anything. Even BarrysFishAndChipShop.OrderMushyPeas() if you have to.

Invest in your own knowledge

Expensive books are cheap

Back in the 1990s books about programming were about 1,000 pages long and cost £50 GBP each (and that’s in 1990s money where you could literally buy a second hand car for that amount, and it would actually drive). There was very little on the internet – especially as I didn’t even have access to it until 1995, and books were pretty much the only source of learning other than chatting with other developers or going to University.

Programming doesn't have to be painful...

I remember a conversation on Usenet (which was a kind of online newsgroup back in the day where like-minded people would gather together to get angry with new people) where someone asked what was a good book for learning C++. One chap answered that he tried to buy at least a book per week on the subject, and this struck home with me.

You see, up until that point I had considered books to be extremely expensive things and you had to make a careful choice as to which one you invested in. What I didn’t appreciate at the time was that when you’re in a field such as software development, the £50 you pay for a decent book can be earned in a single hour as a software contractor. This was a turning point for me, no longer would I be starving my brain of the knowledge it craved, I too would own more than one book about C++. In fact there were times when I bought more than one book in a week.

Another benefit of owning multiple books on the same subject is that you will be getting multiple viewpoints. One author might be an expert at one particular aspect of a programming topic, another author an expert in a different aspect. Yet another author might not be an expert in any of the aforementioned topics, but has 40 years’ experience and pretty much knows what not to do in a given situation etc… Gain your knowledge from as many sources as you can and you shouldn’t end up with any blind spots.

Don’t read programming books

Once I bought a book called “Teach Yourself C in 21 Days”.

After 21 days I still couldn’t program in C and I felt cheated. The book title was a scam and I had been tricked. Afterall I had read most of the chapters in the book, and seemed to understand most of them.

I have to admit it was some time in the future where I realised the problem was with me and not the book. What I had done is read the book without typing a single line of code. It’s all very easy to read a programming book and think “yes, yes, all very straight forward”, but when you sit at a keyboard without the book somehow the obviousness of it all seems very far away and you realise you actually remember very little. Something to do with void and main, or was it main and void?

In order to learn programming, you have to write code. Don’t just read programming examples, sit there and type them in. Even if it seems really obvious to you, type in the examples and run them. I still do that today (sometimes). Recently I bought a book about automated testing using Selenium and practicing what I preach I typed in the code samples from the book. This gave me a real feeling of understanding and the knowledge imparted was much more persistent than if all I did was read the examples and not physically implement them. What’s more I had to resolve issues with the programming environment and other such hurdles which helps give you that working knowledge.

It’s a similar concept to studying at school where hand writing things into an exercise book helps you commit the information to memory far more effectively that just sitting back and listening to a lecturer.

Don’t read programming books, type them into a compiler.

Don’t watch free videos

I think you probably know where I’m going with this…

There are lots of free programming tutorials on YouTube, some of them are even good. But there are a lot of low-quality tutorials out there and finding really good learning material is difficult.

There’s a good reason for that. YouTube is incredibly stingy when it comes to paying its contributors, which means that the highly talented and learned people that you would want to watch on YouTube can’t be tempted to get out of bed to make a video. I hear you cry “but there are YouTube millionaires out there!”, which is true enough. But if you look at the number of views a programming tutorial about “Unit testing with MSTest V2 and C#” gets compared with the number of views a video about eating washing detergent tablets whilst giggling through a game of MineCraft gets, you can see why people eat detergent and film themselves doing it. Let’s face it, a video of someone explaining Liskov’s Substitution Principle isn’t going to go viral, even if they do have soap coming out of the corner of their mouth.

Free videos on YouTube will get you so far, but for good quality tutorial videos you’re going to need to pay for them.

Uncle Bob Martin videos (cleancoders.net) is an excellent source of paid for videos on the topic of software development craftsmanship, and the several hundred dollars they will cost you will repay themselves many times over.

Similarly, PluralSight.com is an excellent source of quality programming videos which are way higher quality than anything you’ll find for free.

Also check out bobtabor.com – Bob Tabor is an excellent instructor and all-round nice guy as well.

Do Your Homework

The software development business is like no other in terms of how much it evolves over time. Frameworks appear and go into legacy support faster than you can become an expert in them, and there is a continual forward movement towards newer and “better” programming paradigms.

That’s not to say everything gets replaced. If you learned a flavour of SQL back in the day it will still be relevant today. But have you familiarised yourself with No SQL databases, or immutable data storage? Have you embraced LINQ?

The changes in our industry are constant and persistent. Sometimes fast and furious but more often subtle and unseen. One day your pretty much up to speed with the latest developments, your programming tools are modern, up to date and razor sharp. The next day you wake up to find you’re a dinosaur. While you were asleep things moved on, and your code is now legacy and your tools are covered in a thin layer of rust. One day you’re cock of the walk, next day a feather duster…

Q) How can you avoid the fossilisation process?

A) Homework.

Yes, good old homework. Many of us spend our days using existing knowledge and tools to earn a crust. We barely have time to get the days work done let alone take time out during the day to gen up on the latest programming paradigms, or to play with new tools. So the only option that lies open to you is to make some time at home and do a bit of homework.

Now you don’t have to stay up each and every night studying computer science from leather bound books. You’d pretty soon get bored with that and stop doing it altogether. Rather try to do little and often. If you’ve heard someone talking about this magical new programming pattern, take a few minutes one evening to look it up. If someone uses a phrase you’re not familiar with (I remember hearing “Idempotent” for the first time and wondering what Egyptian Gods had to do with coding), look it up and find out what it means. If you’re being left behind because you don’t understand automated testing, go back to the beginning of this post, buy two books on the subject and read them while you’re having a bath, then as you’re drying off crack open a test project and have a play.