We all know that habits can be powerful in achieving great things (e.g. timekeeping or exercising/studying regularly) or descending into the depths (smoking, drinking or eating too much).When we think of habits, I guess we mainly think of the latter ones. And once you have a bad habit, it is verily a devil to break out of.
Some really great suggestions for good habits are listed below in helping to write great code but they actually apply to any part of working on an engineering project.
The reason why I mention these habits now is that I have been undertaking a Python programming course to undertake some probably ambitious engineering software projects.
They can be broken down into three areas….
Stick to your original plan and finish the project on time and to the right level of quality. It is easy to slip or abandon your part of a coding project. Doing your part means that the team is supported in the overall project schedule of deliverables. It is always particularly easy to abandon a software project and move onto other things when the going gets tough.
Often engineers go along with an obviously unworkable project plan. Raise your objections early on to the team and manager when mapping out the project. Leaving this to later, means a lot more pain and frustration.
Working as a team and communicating vigorously with each other is critical to the success of the project. Lurching off on your own is a recipe for poor outcomes in the project or perhaps even a disaster.
Be honest about your mistakes and take ownership of your work. Come up with solutions to problems rather than listing them and then sitting back expecting someone else to fix ‘em.
Be totally transparent and free with everything you learn and know. This makes you one of respected members of the team who has a fearsome reputation for openness and generosity.
Don’t be afraid to use other solutions or approaches created by others. Trying to do everything your way costs more and takes longer especially when you consider debugging time. Keep your work and coding to the standards used in the team. Don’t create your own no matter how much you enjoy creating new templates and styles.
Writing of Code
Often you simply don’t have the time to do an immediate fix; but you need a solid system to record what the problem is and what is required. So that it isn’t forgotten.
Often programmers delight in writing tight code which compresses say, 20 lines into one line. But of course it is then totally unreadable to anyone following on later. Someone has to maintain your code or work on it later and you need to think of others coming along later who have to maintain your work. Optimising for the sake of optimising is also a waste of time unless there are real benefits.
It is best to confront problems when they occur and to deal with them in the best way possible. Ranging from changing a PLC rack because you have undersized the number of I/O or remedying defective code now rather than later when it will cost much more.
Too many engineering professionals shy away from good documentation of a program and of naming variables and function names so that they are logical and help with understanding the program. Document and focus on good naming practices.
There are always best practices you can apply in your project. For programming it may be code reviews, test-driven development and good QA practices. They may be more arduous and take longer but they have been designed by veterans who have built them with oodles of experience.
Often we get comfortable with a particular software tool (e.g. the XYZ editor) which may be brilliant for one programming language or project but total inappropriate for another. Learn and accept new ways of doing things even though these changes are often painful.
Often I find code with a ferocious amount of hard coded values in them (e.g. for timers and counters). Think of making things configurable so that you make rapid changes with a simple data configuration file tweak rather than rewriting of wide swathes of code.
Often you have to copy a chunk of code from another project into your program. Inevitably, after a glance you don’t understand how it works but as you are in a rush you simply copy it across. While this may be a short term fix; you may find it creates long term problems with unexpected results as you didn’t understand it. So best to invest the time in understanding it and ensuring it is 100% appropriate for your program or to make adjustments to it early on.
My favourite Robert de Niro quotation is: When there is any doubt, there is no doubt. Never trust anything you have put together without testing it thoroughly. You may have written it and think it is unsurpassed in its brilliance but believe me – until you have tested it – never assume it works properly.
When work is tough and you are having difficulty understanding something or solving a particularly tough problem – persist and then ask for help. Most people are delighted to be able to help you.
Naturally, you are writing code to solve a particular problem. However, there are other perhaps peripheral issues which you need to think about such as cybersecurity, aesthetics and overall performance which may impact on you later. Think of them as well in writing your code.
Thanks to a great article about writing code which stirred some enthusiasm in my flagging efforts in using Python by Christian Maioli on Codementor.io web site entitled: 35 habits that make you write bad code.
Yours in engineering learning
Mackay’s Musings – 20th June’17 #657
125, 273 readers – www.idc-online.com/blogs/