8

Where I work there are a few experienced software developers with a software background, but the majority of developers are physicists or chemists with excellent domain knowledge but limited experience when it comes to developing high quality, maintainable software. To address this we have started running regular talks and workshops.

What topics do you think we should discuss to help make these people more effective software developers?

In particular we are struggling to gain enthusiasm for these talks as many developers do not see software as an interesting subject. How could we make these more interesting to people without a software background?

Thanks

Improve this question
2
  • let me rephrase that - How can I tell truck drivers to get in F1 race ? ( Is it something like this )
    – Ayush Goyal
    Oct 31, 2010 at 19:53
  • To explain our situation better, we are all part of a software department in a large organisation. The history of the company is that the science has in the past been more important than the software, which is why we have a lot of software developers with strong science background. But the company has changed, we are much larger company now (going from ~40 software developers to ~250 across 5 countries) and most of the challenges we have are software not science based.
    – Andy Lowry
    Nov 5, 2010 at 12:30

5 Answers 5

Reset to default
4

I think it's going to be hard, so be prepared for a struggle - but not impossible. At the end of the day programming (especially non-cowboy-hack'n'slash coding) is not going to be super-exciting to everyone. This is especially true for people already working in an area which is intellectually challenging and rewarding in its own right.

First of all make the talks and workshops fun in themselves - free food (make sure it's nice food!) and similar treats are a good place to start. Try to inject a bit of humour too and, at least initially, keep them fairly brief and as informal as you can.

Secondly make sure the talks and workshops are relevant. Try not to make them too abstract (even if the concepts being covered are abstract) and if you possibly can at all, ensure that they can try out what's been covered. Even better check on what they've done between sessions and provide positive feedback. If they're not relevant and they're not applying what you've discussed then they will (correctly) view them as a waste of time.

Finally try to introduce some basic coding standards, preferably ones which are not too intrusive in how they currently operate. If you're in the .net world Resharper is a good one to begin with as it will warn about things like naming conventions. You can take that further with StyleCop (which can be integrated into Resharper) - but make sure you customise the ruleset first. If you're not in .net then I'm sure similar tools will exist elsewhere. It's not much, but it's a start.

Don't expect instant results (except for maybe any automatically enforced coding standards) - I've heard 6, 9 and 12 months bandied around for the time to introduce best practices.

I've only flicked through it so far, but there seems to be a fair bit of good, relevant, advice for you in the forthcoming book Driving Technical Change.

Improve this answer
1
  • Excellent advice, thanks. I have just finished reading the latest beta of Driving Technical Change, which has been very helpful, and I would recommend reading it.
    – Andy Lowry
    Nov 5, 2010 at 12:34
5

If these chemists and physicists are not primarily profesional developers, and are not intended to become so, I would suggest thinking differently at the problem.

The "real" developers should provide easy environments for them to develop into. You should provide mentoring and you should provide peer review of their code with strong incentives to make the code good enough for passing in the first place.

In other words, do not treat them as equals, but provide all you can for them to excel on what they actually do that is their strength.

Improve this answer
2

I work with very smart networking engineers who are not developers and don't want to be. I can understand that because I don't want to be a networking engineer.

What we've found that works well is for the engineer and I to do team-programming. We're at separate sites, so we get on the phone, open a screen sharing session usually with the screen command, and bust out the code.

We've done that many times and felt it worked really well. I'm understanding how they do their thing better, and the engineer is learning how we write maintainable and tested code.

Improve this answer
1

What role do they have in the company? If you need developers, then let them go if they aren't good developers and aren't interested in becoming good developers. If they are supposed to be physicists and chemists, you can run workshops, but don't expect them to maintain a high level of interest. If they're supposed to be both, raise expectations and make sure you're paying them enough to justify them taking on a software developer's role while maintaining complex domain knowledge and skills.

Unless part of someone's defined role is to be a developer, they will probably never be all that interested in developing high quality software. Just because someone is creating quick scripts and hacks doesn't necessarily mean they really want to be a software developer, it's just a means to an end, like an accountant figuring out complex Excel formulas. If you need high quality, maintainable software, then software developers should be creating it.

Improve this answer
1

show them the benefits to them. otherwise, why should they care?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.