[Closed] Writing good software

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, [b]then[/b] 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':

[img] [/img]

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!

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!

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"

[img] [/img]

The hard part is to give them what they need, [i]not[/i] what they say they want.

[img] [/img]

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 [I]hard[/I]

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.

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 [i]very[/i] 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 🙁

oldnpastit - Member
1. KISS. Being stupid is actually an advantage to a computer programmer. Up to a point.

This is important. Don't be clever if you can be simple. Clever is a complete pain to debug and/or maintain. If you have to be clever please document your cleverness in a way that seems like you're explaining it to a moron. Because if you have to fix it in 6 months or a year or even later you'll be feeling like a moron as you scratch your head over the convoluted code your younger, stupider self thought was clever.

This is important. Don't be clever if you can be simple. Clever is a complete pain to debug and/or maintain. If you have to be clever please document your cleverness in a way that seems like you're explaining it to a moron. Because if you have to fix it in 6 months or a year or even later you'll be feeling like a moron as you scratch your head over the convoluted code your younger, stupider self thought was clever.

In addition, it turns out you can't add developers to your project, because your new developers just won't be able to figure out what the blazes you are/were trying to do. Especially if it's anything involving complicated lifetimes and std::shared_ptr<>.

Or so I've heard anyway.

What have you got against std::shared_ptr<> oldnpastit?

Work pretty well in my experience. Certainly a lot less error prone than managing raw pointers . The only real issue I've had is with programmers who are still trying to write in C and just don't understand them.

Bit like in C# world, rewriting everything as LINQ expressions, because it's cool. Actually I fell for that a bit, but ReSharper didn't help as it kept advising this or that could be rewritten in one cool LINQ statement. Looking back at the code and especially if it's someone who doesn't know LINQ and got no idea what's going on there.

Has its place though. A nice bit of LINQ vs some hideous big loop and conditional checks.

There's the opposite end where a team lead or project manager decides to ban the cool stuff because basically they don't understand it, so you're stuck on legacy stuff and have frustrated developers.

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.

My old job was with a small consultancy. We preached the open source way and the contracts said that where possible code would be freely licensed and public, if the client wanted proprietary code the rates were higher...

Worked surprisingly well!