Hi, when i was designing security equipment in the 80-90s (assembler, naturally). I would give a working prototype to a salesman to take home for his kids to play with. It quite often came back with a verbal bug report. (he would ask them how they made it do THAT and reproduce it himself) If his kids could not get it to I knew I was right for initial production If you cannot find any bugs, give it to a kid. They will find one. Fun.

I started professionally in 1980 and still love assembler or even pascal, though I don't use it much now days. Finding IDEs more and more frustrating with their bugs and semantics. It all seems to have dampened the creative side of the challenge. Bloated, badly written libs rule now. Copy and past every where I look. Oh well I am a dinosaur.

I wish someone would come up with a universal rf connector for mobile phone/gps etc connections. The number of connector types is astounding. Drives me nuts. Same problem, different phy.

I thoroughly agree with you on that. As an engineer, I have bumped heads with them as well as the Australian Institute of Engineers. What a mob they both are.

I do would not like to come across that in a piece of code.

The point I was trying to make is. Do not loose heart if someone does not like your style. Everyone has their own style. So long as others can follow your code, does it matter. As a programmer (if you view it as I) you will try to make it as efficient as possible. (think and re-write, think and re-write) Keep a problem area in the back of your mind, it may be working, but you know there is a possible problem there. Do not! copy someone else's style. (this is for the new comers) Make mistakes. Admit it and fix them. A programming style cannot be learnt from a book. I love using multi dimensional arrays. They are efficient, but the code is really hard to follow. Therefore, I have to write a document explaining exactly how the code works. Rambling, I know. Ken.

I am an old programmer. started in 1978. ASM all the way till 2010. yep old school. In 2016 I picked up a gig with a company I left in 1992. Tracking equipment. All C based. No problem. NXP processor. Not bad. MQX RTOS. Bloody night mare. (not an RTOS by the way) Had to drill down and re-write the drivers and part of the OS. The young buck in charge! did not like my style of programming. I did not like his. (macro use every where) Who cares if your style is not liked by someone else. does the end result work? Can someone else follow the code you have produced? If so then job done. Am fed up with programmers trying to copy someone else's style and spending months making it look pretty instead of making a product work using their own style. (if possible) STOP copying and pasting. Without understanding that which you are copying. Anyway. The message is. Develop your own style and progress with that. Ken.

in 83 I had a cpm system running at 4Mhz with an 8" floppy, But also a 10 MEGA BYTE external hard drive, with removable platters. Luxury. The rest of the system was crap. Filled up my car if I took it home to work. Ah. The good old days. ASM all the way.

Sometimes, designing on the fly is the only option. I design the hardware, firmware and software. For systems. A lot of these are multilevel in HW & FW. It is called research and development. Therefore I always include a DB in the design. If not used take it out. Which is easier to do than put it in latter as per encryption. Put encryption as standard. If not required, it does not matter. putting it in later may be annoying. Anyway.

I usually work with dbs. So The db is already included in the virgin app/server code as a basic entity. I also use the db for logging. so its just natural. It is just a part of the system. As per the remote hardware etc.

well said