Programming can be frustrating. For newcomers, sure. But it can be a habit long past that stage, and it was never necessary in the first place. There is a better way.
Programming is frustrating, right? Bugs pile up. Things don’t do what you expect. Spec changes. Technology changes. There’s no time. Changing one thing breaks another. Everything is behind schedule.
Well… no, honestly. It doesn’t have to be that way. It was that way for me. For many years. And then… it wasn’t. A lot of things clicked, and within a short space of time, programming became fun again.
So what happened?
A lot of things. I was dissatisfied with the way coding went for me. I wanted to change. I had time to concentrate on my personal development, and I wanted to use it to be a better, happier programmer.
I wanted to enjoy my work again. All of it. Like I did when I was ten and computers were magical. And it turns out, it’s not that hard.
There are tools and techniques available. Some of them you already have.
There are things you can do to stay on track, and ways to catch it quickly when you veer off. There’s a clear path. Others have walked it. Help is available.
You can get most of the help you need from yourself.
I don’t have all the answers.
I have ideas. I’ve looked in to it a lot. I’m learning all the time.
I’m sharing what seems useful, and encourage the reader to see what works for them.
There are great resources available. People are looking at this and crafting solutions, and have been doing for some time. I hope to give you a general picture of what works.
It takes time. It happens in stages. Having a clear goal in mind can change things much faster than it seems.
There’s a lot to look at. I’m not suggesting there are silver bullets. There are some suggestions that can make a difference quickly. Others take more time.
I’m going to start with general techniques. They can help in many situations, and provide a solid foundation for other, more specific approaches.
Staying grounded is essential. I rarely work on a system without an understanding of the way it’s engineered. At least to a sufficient degree to complete the task at hand. At least.
This perhaps sounds obvious. But it’s not always.
To be able to carry out effective engineering. Effective programming. It helps to to know the engineering of the underlying system.
It’s not enough to know about the options provided. You need to know how and why it works, and how it’s wired together. This enables you to make decisions in harmony with it.
Get to know the system. Start with the core architecture. Build your understanding from there.
Time spent this way is far more valuable than time spent researching solutions to problems. You will come up with the solutions yourself. Because you understand the system.
You will change to approaches that don’t create disharmony in the system. Problems will evaporate before they occur. You will save time in the long run.
You will come up with the solutions yourself. Because you understand the system.
Ground Problems to Solve Them
When you’re dealing with a problem, but have no clear solution, and are lost with where to go next, examine the threads of the system, as they affect the problem at hand.
Build a picture of the engineering in your mind. Follow the threads through and check your understanding. Write it down or draw a diagram.
Identify any areas of the system that are at play but not fully understood. Take the time to understand them.
Not just as it relates to the problem at hand. Get to know that area of the system as a whole. Leave the problem for the next day. Take an hour or two in the evening to study. Come back to it the next day.
Build a picture of the engineering in your mind. Follow the threads through and check your understanding.
Next time you find yourself frustrated by a problem… stop. Walk away from the computer. Breathe. Really stop. Really breathe. Really walk away from the computer. Don’t think about the problem. Give yourself a minute. Give yourself ten.
Do whatever it is that you do. Get a tea. Get a coffee. Go for a walk. The trick is to really get away from the problem. The solution will come to you. At least, the next step. Give it space. Take your mind off it. See it from a different perspective. The next step will come to you. Don’t force it.
This can be difficult. I’m not saying it’s easy. It’s hard to do this when the pressure is on, and it seems like there’s nothing you can do but sit there until it’s fixed.
Maybe you need to do that. But mastering this technique will help you sit there more effectively, without getting lost down rabbit holes, and losing sight of where you are.
You’ll take a steady approach, and find the next step to solving the problem.
Give it space. Take your mind off it. See it from a different perspective.
Segue: Supporting Techniques
None of this is to say that there are not approaches for tackling problems directly. Breathing and grounding help us to choose the next step. And to choose wisely.
Some techniques are analytical, working directly on problems to determine solutions. Others are engineering practices that reduce the occurrence of defects overall. I will look at some of these in future articles.
Breathing and grounding help us to choose the next step. And to choose wisely.
Stepping away takes the idea of breathing, of getting away from the problem for a moment, and levels it up a notch. It’s not always needed, but it’s a useful technique when it is.
This is about entirely stepping away from the problem itself.
Not just looking at it from a different angle. But considering different points of view entirely. Different approaches to the whole circumstance, not just the specific problem.
Ask yourself, do I actually need to solve this problem? Is there some other way that this whole situation could be, that could mean this problem did not exist? Or, not in its current form? What are the general factors at play here? What are the boundaries of the game? How might they be changed?
Actually go there. Actually try it. See it through as an idea. See what difference that approach could make to the situation you’re dealing with. You might come back with a solution you never dreamt of. Or you might find there is a deeper problem to solve.
Ask yourself, do I actually need to solve this problem?
Summing Up: Grounding, Breathing, Stepping Away
Stepping away is similar to grounding, but more creative. It looks to travel to a different context, and take a view from there. As opposed to grounding, which is getting clear on the circumstances at hand, and avenues for approaching the problem.
Grounding comes first. Stepping away is an option if you need it. It can be helpful to ground the ideas that you look at when you step away. There are a whole range of techniques that can be used before looking at stepping away. It’s there when you need it.
They don’t need to take much time. Once you understand the system, and gain some experience, building a picture of the threads affecting a situation; seeing alternative avenues for solving a problem; and taking another point of view; will all come more easily to you. Breathing helps.
Grounding, breathing and stepping away are all techniques that can help quickly as you adjust to them. They are a way of switching the tracks when things get tough. It will take some time to integrate them and make them work for you.
They are a way of switching the tracks when things get tough.
Bonus: Embrace Consistency
When you work with software, you expect it to be consistent. It is. And if it’s not, it’s usually a sign that something is wrong with your code. It’s how software works. Given the same parameters, you get the same output. The same principle can work for you with the code that you write.
Be consistent with coding style throughout your project. Do the same things in the same way. Use the same approaches to similar problems. Put the code in the same order. Favour consistency over being creative. Use the approaches that are already in place on a project. Get to know what they are.
Don’t use the latest approach, if some other solution is already used. Take trade-offs that promote consistency. If an updated approach is needed, implement it across the project. Either all at once or incrementally.
This pays off when you come back later. Being able to rely on consistency means that you can come back to that code and know how it works. Because you already know how things are done on the project, and because it’s consistent, you don’t need to check . It saves time. It reduces frustration.
Consistency may not always be possible. It may not always be desirable. But it usually is. It’s a great default. Every piece of the system that is consistent with another is one less that you need to understand.
I hope this has been useful to you. These techniques are an important part of my approach to software engineering. They help me keep track when things get sticky. Perhaps they can help you too.