My guide to writing good software:

1. KISS. Being stupid is actually an advantage to a computer programmer. Up to a point.
2. Two mutexes good, four mutexes bad.
3. C++. Just say no.
4. std::shared_ptr<>. See item 3. No, it does *not* prevent memory errors or leaks, it just makes them harder to figure out.
5. If it hasn’t been tested, it doesn’t work.

std::shared

This doesn’t sound like the way to win friends.

6. Testing means verifying that the things that shouldn’t happen don’t, not just that the things that should happen do.

3a. Java. Just say no.

7. There must be a better way (not my words, I stole them from one of the Python Devs that does a lot of software training)

Understand the user needs
Understand the user needs
Understand the user needs
Build the smallest thing possible

8. Profile first, then optimize. Don’t just do the cool thing you’ve fancied doing for ages.

9. Contribute back. Whether is is code in an open source project or documentation or other things doesn’t matter. But contribute. It makes you a better dev

Rachel

I refer to the Klingon Programmers Manual which is very short.

Documentation is for the weak and timid.

10. Stack Overflow + Google 😉

Until someone else has used it, it doesn’t work

Understand the user needs

+1

As an example of ‘Clever Design vs User Experience’:

1. Best not done on Friday afternoon after the lunchtime beers. Makes the coding sail along, but the debugging on Monday is another matter entirely.

2. Googling about R is difficult, until you learn to add “project” to the search terms.

3. A sufficiently talented coder can write fortran in any language.

11. Write decent comments! Tell me why a line of code exists, not what it does – I can see that by looking at it!

12. Don’t code when your brain is toffee, surf STW instead, it’ll save you uncoding everything later.

13. Imagine reading the code you’ve written at 03:00, after being dragged out of your bed for a call out. Can you still understand what it’s doing?

Disagree with 3 by the way. Nowt wrong with well written C++.

FWIW, I’m currently working on legacy safety-critical medical software controlling delivery of radiation and it uses a mixed bag of C, C++, C# and… Visual Basic! 😯

FWIW, I’m currently working on legacy safety-critical medical software controlling delivery of radiation and it uses a mixed bag of C, C++, C# and… Visual Basic!

sounds like something that I designed 🙂

FWIW, I’m currently working on legacy safety-critical medical software controlling delivery of radiation and it uses a mixed bag of C, C++, C# and… Visual Basic!

That’s quite disturbing. C# and VB require windows, and i’d never trust anything safety critical to run on windows – it has far too much of a mind of its own.

9. Contribute back.

Work don’t let me and these days I have very little inkling to do even more coding in my spare time.

9. Contribute back.

Work don’t let me and these days I have very little inkling to do even more coding in my spare time.

You learn an awful lot if you do though. You’ll find a few tiny contributions from me inside git, it’s well worth it.

EDIT: which reminds me: code is read far more times than it is written.

That’s quite disturbing. C# and VB require windows

Can’t say too much for obvious reasons, but yes it does involve Windows Embedded Standard (i.e. restricted version of XP) but the real-time stuff is handled on LynxOS.

Disagree with 3 by the way. Nowt wrong with well written C++.

Is there an existence proof for this?

A friend went to a lecture by Bjarne Stroustrup, where BJ talked at length about the kinds of problems people were having with the terrible code people were writing, and what was being done in the language to make this better.

At the end, he asked for questions. My friend said, “you’ve given us lots of examples of C++ projects with badly written code, can you give us an example of a well written one?”.

There was a long pause. And then the great man replied, “No”.

There are no well written C++ programs in existence.

I’m pretty sure no one intentionally writes bad code, it just happens as a product of circumstances…

Is there an existence proof for this?

Well I do a lot of work in embedded software. The options there are basically assembly, C or C++.

And even then it is often a restricted subset of C++ (e.g. no heap allocation allowed!)

But you are surrounded by embedded software that generally works very well.

Don’t work for Equifax do you. GrahamS? 😉

Rachel

1. Best not done on Friday afternoon after the lunchtime beers.

Does this still happen? I remember the guy who effectively ran the network for a government department being useless after lunch, and I also remember the look of bewilderment when the US company that got the outsourcing contract heard there was a bar on site.

Don’t work for Equifax do you. GrahamS?

Hey, it worked on my machine.

I also remember the look of bewilderment when the US company that got the outsourcing contract heard there was a bar on site

Once, when working on the (surprisingly complex) embedded software for a car door, we went over to the plant in northern Spain to work with the engineers there.

All kinds of machines assembling car parts, as well as other machines testing them (robots opening and closing doors, sitting on seats etc, just like the adverts only much dirtier).

Their “software department” was literally 3 guys in a corner of the plant, writing code and backing it up to zip files in “My Documents”. No source control. No build servers. DevOps didn’t really exist in those heady days.

Anyways, on the factory floor they had vending machines full of beer, and the two hour lunch break involved a three course meal and a carafe of wine!

Happy days.

Having had all my R&D move to India and China, I’m wondering if this page can be translated into Hindi and Mandarin 🙄

1: “Build things people want”

The rest is quite frankly trivial details if you’ve got this bit right.

In my experience mrblobby, you’ll get five folk on an Indian team. One will speak good enough English to be the “project lead” and will say yes to absolutely everything even if they have no idea what you mean. One will actually know what they are doing and do all the real work. And the other three will be getting some on-the-job training from the one that knows what they are doing.

As with all outsourcing, managing it with your own tests, quality reviews, milestones etc is the key. Sadly most companies seem to think they can just push it out the door and forget about it.

1: “Build things people want”

The hard part is to give them what they need, not what they say they want.

Documentation is for the weak and timid.

14. (or whatever number we’re up to now) The code, by definition, documents exactly what it does and how it works, more accurately than any other written documentation.

The code, by definition, documents exactly what it does and how it works, more accurately than any other written documentation.

But it doesn’t tell you WHY

Good documentation is hard

Rachel

The hard part is to give them what they need, not what they say they want.

Absolutely, which is exactly what I’ve made a career out of. (UX Designer)

Never let Sales decide the features based on what they think the customer wants or what they personally want to be able to get that sale commission.

End user documentation – no-one RTFMs, don’t bother. UI should be self explanatory. If not, invest in support. Even with comprehensive documentation, they’ll still ring support first.

mrblobby – Member 
Having had all my R&D move to India and China, I’m wondering if this page can be translated into Hindi and Mandarin

Copy all this and paste it onto Stack Overflow. It’s where they’ll be looking anyway 😉

As a lead developer looking after a team of contractors, I generally didn’t put rules onto my staff – just once principle –

Your goal should be to write readable, maintainable and efficient code.

If you don’t do that and I spot it in a code review, you’re doing it again.

Also, it’s twice as hard to debug code as it is to write it, so don’t be as clever as you can be when you write code as you’ll need a genius to debug it…

9. Contribute back.

Work don’t let me and these days I have very little inkling to do even more coding in my spare time.[/quote]

If you use open source software in any meaningful way, and scratch an itch by fixing spelling in the manual, or fixing a small bug, or implementing a new feature, then there are generally ways to convince work to let you.

One option is to not mention the company at all (loads of contributions in projects I work on come from China in Chinese working hours via @gmail.com), or the worst case of Legal+CTO vetting each project you submit to. Either way, aside from not having patches locally which can be a pain on upgrades, contributing back to an open project means you build up a relationship with the developers, so when you *need* help they’re more willing to help.

We have made it so that when helping patch Drupal code, you can declare any employer and client you want as “supporting” the time needed to do the work. Then, that gets added up and used to push that employers profile higher on the Drupal marketplace section of the website.

It’s a very neat system.

Rachel

there are generally ways to convince work to let you.

I am a full-time employee to a company that essentially contracts us out to other companies. Any work off the clock or that could be construed as threatening privacy of a client would be very frowned upon.

Even stuff like StackOverflow questions have to be very careful.

If a client tells me to contribute to open-source I gladly will, but otherwise, not a chance.

Ugh documentation… don’t even get me started on technical documentation being written and interpreted by Indians and Chinese in second/third language English 🙁