|
|
|
|
|
|
by collyw
4415 days ago
|
|
|
Depends on what you want to do. I see lots of bioinformaticians writing simple scripts usually just counting stuff up, and doing some stats. It needs to run once, on one machine and often only on one dataset. That type of programming is easy. I am working for a sequencing centre, doing the database to run the place. I inherited a self taught bioinformaticians code after she had left. Second worst code I have ever seen (the worst was also a self taught bioinformatician, who didn't even indent stuff). The code was so bad, I had to refactor it just to debug it. The team leader didn't see a problem. It had worked. He didn't see the fact that it would have taken me a day or two to write this from scratch, if I had had an original specification, rather than spending a week to refactor her code until it worked. To this day, I have no idea what parts of the code are doing (I can see it is reading byte 8 of a binary file and doing something. I have no idea what the contents of that file are). At least now I have made the code modular so I can see the output of reading the file into a huge nested dictionary. Learning to code is easy. Learning to code well is not. Hell we can't even decide what coding "well" means. 100% test coverage? Shit that works? Something that is readable and maintainable? Something that runs faster than all the equivalent software? In the end I think experience will mean a developer can work out which of these is most important. Maybe just getting something that works is what is important, and the example I gave above is perfectly acceptable code. |
|
|
I've spent a lot of time doing embedded stuff. Totally different world. What matters here is irrelevant elsewhere.
So any time someone says "I can program" you have to ask "Where? With what tools? For what audience?" and so on. Because there are so many niches (and so many being invented every week) its impossible to guess.