16 Habits to Write Brilliant Engineering Code or Run a Brilliant Engineering Project

Dear Colleagues

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….

• Team work
• Writing of code
• Commissioning and Maintenance

Teamwork

1. Finish the Project as Planned

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.

1. Ensure your Project is workable

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.

1. Work with the Team; not in Solitary Desolation

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.

1. Blaming Every Other punter but yourself

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.

1. Share your knowledge and experiences freely

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.

1. Don’t Reinvent the Wheel

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

1. Fix It Later

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.

1. One Liners Don’t work – Readable Code is the Key

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.

1. Don’t hide Problems

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.

1. Ensure Documentation and Naming Conventions are Top Class

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.

1. Thrive on Best Practice

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.

1. Apply the Right Tool for the Job

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.

1. Try and Generalise Code

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.

1. Randomly Copying 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.

1. Never Trust Anything

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.

1. Never fear asking for Help

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.

1. Remember peripheral but critical issues

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

Steve

Mackay’s Musings – 20th June’17  #657
125, 273 readers – www.idc-online.com/blogs/